Re: separating flags from noteheads in font (issue4273119)
LGTM. http://codereview.appspot.com/4273119/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: separating flags from noteheads in font (issue4273119)
2011/6/11 : Looks good, but untested. I'll test it when I can. Ok. Don't forget to make clean in build/mf - there are still missing dependencies. Thanks! http://codereview.appspot.com/4273119/diff/3001/mf/feta-noteheads.mf File mf/feta-noteheads.mf (right): http://codereview.appspot.com/4273119/diff/3001/mf/feta-noteheads.mf#newcode45 mf/feta-noteheads.mf:45: numeric black_notehead_width; On 2011/06/10 23:12:15, Carl wrote: Perhaps a comment here to indicate that we have deliberately *not* used a save statement for black_notehead_width in order to allow it to be a global variable available for other .mf files. This will help keep people from saying "Hey -- good practice says to make local variables; let's make it local" Done. http://codereview.appspot.com/4273119/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Duplication in NR 1.6.3 - snippets no longer needed?
On 6/10/11 12:05 AM, "Keith OHara" wrote: > James Lowe datacore.com> writes: >> >> I think we have some duplication in this section but would like a second >> opinion > > I agree. The two snippets do not need to be quoted in the documentation > because > you cover all the concepts earlier. I concur. The Selected Snippets have no reason for being; the same concepts are taught in the main text, and there is no reason the snippets need to be selected snippets (i.e. they don't use \override or \set (except for the instrument name). Please eliminate the selected snippets. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: separating flags from noteheads in font (issue4273119)
Looks good, but untested. I'll test it when I can. http://codereview.appspot.com/4273119/diff/3001/mf/feta-noteheads.mf File mf/feta-noteheads.mf (right): http://codereview.appspot.com/4273119/diff/3001/mf/feta-noteheads.mf#newcode45 mf/feta-noteheads.mf:45: numeric black_notehead_width; Perhaps a comment here to indicate that we have deliberately *not* used a save statement for black_notehead_width in order to allow it to be a global variable available for other .mf files. This will help keep people from saying "Hey -- good practice says to make local variables; let's make it local" http://codereview.appspot.com/4273119/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
On 6/10/11 2:53 PM, "Janek Warchoł" wrote: > Carl, > > 2011/6/10 Carl Sorensen : >> It may be as simple as eliminating the save statement for >> black_notehead_width. > > it works! You are a GENIOUS!! > I'm sure that genius is too strong a word to apply to me, but thanks for the kind words. Even a blind squirrel finds a nut every once in a while. I'm glad it worked for you! I've looked at your Rietveld patch, but I won't be able to actually test it until sometime later, but it may be a few days. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: No more releases: savannah sometimes does not like git fetch --depth
Trevor: > I've attached an email which explains a similar problem ... Path-mtu-discovery is described in rfc-1191 and some problems with it in rfc-2923. The symtoms described in is matches "black hole" in rfc-2923. It should be wholly agnostic to the "git fetch --depth 1" vs. "git clone" choise. The "black hole" problem happens only for large packets. ** If it is the "black hole": The best fix is to correct your router, setting the mtu in the router might be a solution for that, but your router should return a proper icmp error response (ICMP Destination Unreachable messages with a code meaning "fragmentation needed and DF set") if the packet is too large. Make sure the router and your host don't filter out thoose icmp packets. /// The second best is to send smaller packets from your host going through that route. This can be set with route del default gw route add default gw mss where mss = maximum segment size. A good first try is MTU - 80, see rfc-879 for details. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: separating flags from noteheads in font (issue4273119)
with Carl's help, new patch set was uploaded. Now the flags aren't squished, so it's perhaps ready to go :) http://codereview.appspot.com/4273119/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
Carl, 2011/6/10 Carl Sorensen : > > On 6/10/11 5:43 AM, "Janek Warchoł" > wrote: >> Unfortunately i still don't know how to extract the information about >> black_notehead_width. It should be made some kind of a global >> variable, but the main problem is that its value is not specified >> explicitely, but it's a result of a drawing operation. > > I've looked at this some more. In feta-noteheads.mf, line 39, we do > > save black_notehead_width > > which establishes black_notehead_width as a local variable to the group. > > It may be as simple as eliminating the save statement for > black_notehead_width. it works! You are a GENIOUS!! I would never think about doing what you suggested. I'll update Rietveld issue; i also attach a patch if anyone wants to test it. I'll be working all day tomorrow, but i hope to write a first draft of feta-flags-autometric on Sunday. thanks! Janek From c02ea4247918fd7e220df618674c3c0d24553c50 Mon Sep 17 00:00:00 2001 From: Janek Warchol Date: Fri, 10 Jun 2011 22:43:29 +0200 Subject: [PATCH] separating flags from noteheads until now, feta-noteheads contained both flag glyphs and notehead glyphs. This patch separates them - new "family" of feta-flags files is created. --- mf/GNUmakefile | 10 ++ mf/bigcheese.pe.in |1 + mf/feta-flags-generic.mf| 52 +++ mf/feta-flags11.mf | 13 mf/feta-flags13.mf | 13 mf/feta-flags14.mf | 13 mf/feta-flags16.mf | 13 mf/feta-flags18.mf | 13 mf/feta-flags20.mf | 13 mf/feta-flags23.mf | 13 mf/feta-flags26.mf | 13 mf/feta-noteheads-generic.mf|7 +--- mf/feta-noteheads-test-generic.mf |7 mf/feta-noteheads.mf|2 +- scripts/build/gen-emmentaler-scripts.py |1 + scripts/build/mf-to-table.py|2 + 16 files changed, 172 insertions(+), 14 deletions(-) create mode 100644 mf/feta-flags-generic.mf create mode 100644 mf/feta-flags11.mf create mode 100644 mf/feta-flags13.mf create mode 100644 mf/feta-flags14.mf create mode 100644 mf/feta-flags16.mf create mode 100644 mf/feta-flags18.mf create mode 100644 mf/feta-flags20.mf create mode 100644 mf/feta-flags23.mf create mode 100644 mf/feta-flags26.mf delete mode 100644 mf/feta-noteheads-test-generic.mf diff --git a/mf/GNUmakefile b/mf/GNUmakefile index c47b269..90cbd77 100644 --- a/mf/GNUmakefile +++ b/mf/GNUmakefile @@ -65,6 +65,7 @@ $(outdir)/emmentaler-%.otf\ $(outdir)/emmentaler-%.woff: $(outdir)/emmentaler-%.pe \ $(outdir)/feta%.pfb \ $(outdir)/feta-noteheads%.pfb \ + $(outdir)/feta-flags%.pfb \ $(outdir)/feta-alphabet%.pfb \ $(outdir)/parmesan%.pfb \ $(outdir)/feta%.otf-table \ @@ -83,40 +84,49 @@ $(outdir)/%.pfb: $(outdir)/%.log $(outdir)/%.otf-table: $(outdir)/%.lisp cat $< $(if $(findstring brace,$<),,$(subst feta,parmesan,$<)) \ $(if $(findstring brace,$<),,$(subst feta,feta-noteheads,$<)) \ + $(if $(findstring brace,$<),,$(subst feta,feta-flags,$<)) \ $(if $(findstring brace,$<),,$(subst feta,feta-alphabet,$<)) > $@ ## ugh -- we want this to prevent failing -j2 compiles. $(outdir)/feta26.otf-table: $(outdir)/feta26.lisp \ $(outdir)/feta-noteheads26.lisp \ + $(outdir)/feta-flags26.lisp \ $(outdir)/parmesan26.lisp \ $(outdir)/feta-alphabet26.lisp $(outdir)/feta23.otf-table: $(outdir)/feta23.lisp \ $(outdir)/feta-noteheads23.lisp \ + $(outdir)/feta-flags23.lisp \ $(outdir)/parmesan23.lisp \ $(outdir)/feta-alphabet23.lisp $(outdir)/feta20.otf-table: $(outdir)/feta20.lisp \ $(outdir)/feta-noteheads20.lisp \ + $(outdir)/feta-flags20.lisp \ $(outdir)/parmesan20.lisp \ $(outdir)/feta-alphabet20.lisp $(outdir)/feta18.otf-table: $(outdir)/feta18.lisp \ $(outdir)/feta-noteheads18.lisp \ + $(outdir)/feta-flags18.lisp \ $(outdir)/parmesan18.lisp \ $(outdir)/feta-alphabet18.lisp $(outdir)/feta16.otf-table: $(outdir)/feta16.lisp \ $(outdir)/feta-noteheads16.lisp \ + $(outdir)/feta-flags16.lisp \ $(outdir)/parmesan16.lisp \ $(outdir)/feta-alphabet16.lisp $(outdir)/feta14.otf-table: $(outdir)/feta14.lisp \ $(outdir)/feta-noteheads14.lisp \ + $(outdir)/feta-flags14.lisp \ $(outdir)/parmesan14.lisp \ $(outdir)/feta-alphabet14.lisp $(outdir)/feta13.otf-table: $(outdir)/feta13.lisp \ $(outdir)/feta-noteheads13.lisp \ + $(outdir)/feta-flags13.lisp \ $(outdir)/parmesan13.lisp \ $(outdir)/feta-alphabet13.lisp $(outdir)/feta11.otf-table: $(outdir)/feta11.lisp \ $(outdir)/feta
Re: parameters in metafont files
Oops, forgot to cc to the list... 2011/6/10 Janek Warchoł : > 2011/6/10 Marc Hohl >> >> Am 10.06.2011 13:43, schrieb Janek Warchoł: >>> >>> [...] >>> Unfortunately i still don't know how to extract the information about >>> black_notehead_width. It should be made some kind of a global >>> variable, but the main problem is that its value is not specified >>> explicitely, but it's a result of a drawing operation. >>> I searched for metafont resources on the web, but they seem to be very >>> limited. I found http://metafont.tutorial.free.fr/, but it's about >>> drawing operations, not structural problems. There also seems to be no >>> active forum about it... >>> Han-Wen, Werner, Keith, Marc - IIRC you are the people who work with >>> fonts. Do you know how to do this and if it's possible at all? >> >> Perhaps my answer is too simple, but mf/feta-generic.mf says: >> >> %% this is a fallback so we can run the font without including >> feta-noteheads. >> black_notehead_width# := 1.0 staff_space#; >> >> and the same holds for mf/feta-noteheads-generic.mf. Does that work for you? > > Nope. This is only a dummy value, put there so that other functions > using black_notehead_width don't complain. When compiled with this > value, the result is squished flags: > http://imageshack.us/photo/my-images/829/screenshotpxx.png/ > Of course i can write a more appropriate value there (notehead is > approximately 1.315 ss wide), but such hardcoding is bad. > thanks, > Janek > > PS perhaps it would be a good idea to write in the comment that this > is a dummy value. I was fooled by it like you at the beginning :) > ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
On 6/10/11 5:43 AM, "Janek Warchoł" wrote: > 2011/6/10 Carl Sorensen : >> >> On 6/9/11 3:18 PM, "Janek Warchoł" wrote: >> >>> I remember that i tried doing this separation, but >>> something didn't work. I hope i have that draft somewhere though. >> >> I think that what causes problems is you lose the definition of >> black-notehead-width (which comes from feta-noteheads). > > Yes. > I discovered that my previous try is available as Rietveld issue: > http://codereview.appspot.com/4273119/ > Unfortunately i still don't know how to extract the information about > black_notehead_width. It should be made some kind of a global > variable, but the main problem is that its value is not specified > explicitely, but it's a result of a drawing operation. I've looked at this some more. In feta-noteheads.mf, line 39, we do save black_notehead_width which establishes black_notehead_width as a local variable to the group. It may be as simple as eliminating the save statement for black_notehead_width. Alternatively, it may involve expanding the group, instead. But I haven't worked that out yet. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 1: python formatting
2011/6/6 Graham Percival > > On Mon, Jun 06, 2011 at 11:11:00AM +0200, Jan Warchoł wrote: > > 2011/6/6 Graham Percival > > > > > > Proposal: let’s follow PEP-8. > > > http://www.python.org/dev/peps/pep-0008/ > > > > > > * use 4 spaces per indentation level > > > * never max tabs and spaces > > > * Code indented with a mixture of tabs and spaces should be > > > converted to using spaces exclusively > > > > Do you suggest to follow all PEP-8 guidelines or only the ones mentioned > > above? > > Only the above. 79 chars would be nice, but at the moment I don't > think we need to officially disallow it. Ok. +1 Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [wishlist] enhancing text spanners
Hi Phil, Phil Holmes philholmes.net> writes: > I can't find a reference to this request - could you repost it, please? This is the thread: http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/29244/focus=36655 > What's that in Euros? Currently more or less 25-30 €, but bitcoin raises very quickly (not today). Here the charts: http://bitcoincharts.com/markets/ Ciao! Carlo ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [wishlist] enhancing text spanners
- Original Message - From: "Carlo Stemberger" To: Sent: Friday, June 10, 2011 1:49 PM Subject: Re: [wishlist] enhancing text spanners Hello, LilyPond 2.14 is released, so I reopen this thread. Could you put this request into your track, please? I can't find a reference to this request - could you repost it, please? I offer 1.35 bitcoins bounty. What's that in Euros? Thank you! Carlo -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [wishlist] enhancing text spanners
Hello, LilyPond 2.14 is released, so I reopen this thread. Could you put this request into your track, please? I offer 1.35 bitcoins bounty. Thank you! Carlo ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
2011/6/10 Carl Sorensen : > > On 6/9/11 3:18 PM, "Janek Warchoł" wrote: > >> I remember that i tried doing this separation, but >> something didn't work. I hope i have that draft somewhere though. > > I think that what causes problems is you lose the definition of > black-notehead-width (which comes from feta-noteheads). Yes. I discovered that my previous try is available as Rietveld issue: http://codereview.appspot.com/4273119/ Unfortunately i still don't know how to extract the information about black_notehead_width. It should be made some kind of a global variable, but the main problem is that its value is not specified explicitely, but it's a result of a drawing operation. I searched for metafont resources on the web, but they seem to be very limited. I found http://metafont.tutorial.free.fr/, but it's about drawing operations, not structural problems. There also seems to be no active forum about it... Han-Wen, Werner, Keith, Marc - IIRC you are the people who work with fonts. Do you know how to do this and if it's possible at all? Otherwise i'll simply hardcode the value, but it'll be very rude (and a little wrong in fact - feta26 notehead width is 1.316 while feta11 notehead width is 1.306). >>> Glad to be of help! I really do like your work, and I want to see it >>> implemented in LilyPond. >> >> I'm so happy to hear this! Sometimes i have the impression that noone >> really cares. >> And wait till i start another project! It's gonna be about ties ;) >> Maybe i'll finish it before Lily 3.0... > > Great! I was sarcastic ;) in fact i want to do it in 1-2 months; some help from development team will be necessary for this ofc. Now i know that i cannot work longer than 2 months on a project, i'm going nuts after that time. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened flags: choosing appropriate flag (issue4410049)
On 10/06/11 09:30, lemniskata.bernoull...@gmail.com wrote: > Ian, > > thanks for review! > http://codereview.appspot.com/4410049/diff/16001/lily/stem.cc#newcode792 > lily/stem.cc:792: > On 2011/06/09 04:55:10, Ian Hulin (gmail) wrote: >> /* >> Look up the font character allowing for the variant stem length >> */ > > I don't get it... > That block comment is what I understood the next statement to be doing , and it's the fix in that routine. If I've understood it wrong, change the comment words, and it shows the need for a comment! Cheers, Ian >> You've done a lot of heavy lifting to get here, this is the fix; > > Thanks :) > >> shout about it for the benefit of maintainers. > > I'm shouting, but maybe my voice is too soft :) > > http://codereview.appspot.com/4410049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened flags: choosing appropriate flag (issue4410049)
On 2011/06/09 08:12:53, MikeSol wrote: Hey Janek, All the metafont stuff looks good! Last time we touched base, I recall that we had talked about looking into embedding a lot of this info into the font - did that prove to be not doable? Other than that, I have one comment below about the C++ stuff. I'm working on it with Carl's help, see "parameters in metafont files" thread. http://codereview.appspot.com/4410049/diff/16001/lily/stem.cc#newcode612 lily/stem.cc:612: I remember we worked on a Scheme version of this a while back - I would suggest that you replace this bit of code with that. It'll be easier to maintain and debug, and it also hardcodes less values. There is also a problem with the already computed bit - you are assuming that people will not change fonts midway through a work. I have your patch. I remember that i had send you my comments describing your code, so that you could check whether i understood it correctly. Did you read it? Its in "And still cleaner..." thread, message sent on April 25th. cheers, Janek http://codereview.appspot.com/4410049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened flags: choosing appropriate flag (issue4410049)
Ian,
thanks for review!
http://codereview.appspot.com/4410049/diff/16001/input/regression/shortened-flags-cues.ly
File input/regression/shortened-flags-cues.ly (right):
http://codereview.appspot.com/4410049/diff/16001/input/regression/shortened-flags-cues.ly#newcode6
input/regression/shortened-flags-cues.ly:6: }
On 2011/06/09 04:55:10, Ian Hulin (gmail) wrote:
Spelling nitpick:
chosing => choosing
Done.
http://codereview.appspot.com/4410049/diff/16001/input/regression/shortened-flags-cues.ly#newcode11
input/regression/shortened-flags-cues.ly:11: \new CueVoice {
On 2011/06/09 04:55:10, Ian Hulin (gmail) wrote:
Use four-space indents in this file rather then eight-space ones.
Done.
http://codereview.appspot.com/4410049/diff/16001/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/4410049/diff/16001/lily/stem.cc#newcode757
lily/stem.cc:757: when a flagged stem has manually overriden length, the
flag should be
On 2011/06/09 04:55:10, Ian Hulin (gmail) wrote:
Nitpick:
overriden => overridden
Done.
http://codereview.appspot.com/4410049/diff/16001/lily/stem.cc#newcode790
lily/stem.cc:790: else
On 2011/06/09 04:55:10, Ian Hulin (gmail) wrote:
// (flag_style is not blank)
It's been a long time since the if() and there was lots of involved
stuff in the
then {} clause.
Done.
http://codereview.appspot.com/4410049/diff/16001/lily/stem.cc#newcode792
lily/stem.cc:792:
On 2011/06/09 04:55:10, Ian Hulin (gmail) wrote:
/*
Look up the font character allowing for the variant stem length
*/
I don't get it...
You've done a lot of heavy lifting to get here, this is the fix;
Thanks :)
shout about it for the benefit of maintainers.
I'm shouting, but maybe my voice is too soft :)
http://codereview.appspot.com/4410049/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with beam collision (was: problem with cross-staff stems, on lilypond-user)
Janek Warchoł gmail.com> writes:
> The change is almost certainly due to new beam collision algorithm.
> I'm forwarding this message to the development team so that they will
> know about this issue.
> I'm not sure if it's a bug, though
I think it is a documentation issue. Sometimes we need to turn off the new
automatic collision avoidance by beams.
\version "2.12"
<<
c'2
\new Staff <<
%% The cross-staff chord below worked until about 2.13.50,
%% but now we need another override.
%% I thought there was a nice way to say it is okay for beams to cross stems
%% but I can't find it now.
% \override Staff.Beam #'details #'collision-voice-only = ##t
\clef bass
\new Voice {\stemUp g8 g8 g8 g8 }
\new Voice {
\override Stem #'cross-staff = ##t
\override Stem #'length = #20
c2
} >> >>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
