Re: Ends of barlines are hidden in staff lines. (issue 4809057)
On 2011/08/25 07:59:35, MikeSol wrote:
Make sure to consider cases like:
\relative c'' {
\stopStaff
\override Staff.StaffSymbol #'line-count = #1
\startStaff
b1
\stopStaff
\revert Staff.StaffSymbol #'line-count
\startStaff
b1
}
There are no problems with this example.
Pushed as b92ea16ef75d8aaa7bdb9f492b58d7af906e7945
http://codereview.appspot.com/4809057/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: update the address of git-cl source files (issue 4967054)
On 2011/09/05 21:39:45, Graham Percival wrote: LGTM, please push. Pushed as 750272684023f99e093d5f412172d55da37e014a Thanks http://codereview.appspot.com/4967054/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Prevents nested tuplets from colliding. (issue 4808082)
Mike says this is not yet ready for pushing in comment #11. We should not push while he is away without his confirmation. Trevor http://codereview.appspot.com/4808082/diff/45009/lily/tuplet-bracket.cc File lily/tuplet-bracket.cc (right): http://codereview.appspot.com/4808082/diff/45009/lily/tuplet-bracket.cc#newcode285 lily/tuplet-bracket.cc:285: if (!scm_is_pair (scm_x_span) || !scm_is_pair (scm_positions)) Should issue programming error if user has specified invalid value for 'positions. http://codereview.appspot.com/4808082/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Added \compoundMeter function to NR (issue 4837050)
Janek On Mon, Sep 5, 2011 at 9:54 PM, janek.lilyp...@gmail.com wrote: James, i see this patch is quite orphaned despite being very nice and ready-to-go. Shall i push it for you? cheers, Janek http://codereview.appspot.com/**4837050/http://codereview.appspot.com/4837050/ Thanks for the offer, that's nice of you, however the patch no longer applies to current master. :/ I need to make a new patch. It's because of a combination of things; I was (and am still) waiting on Francisco to know if I can remove the old compound meter examples in the snippet refs in the various translation tely files (I have asked him for a review a couple of times and emailed directly but had no response) and then I was away for a couple of weeks and the patched files are now out of sync. I'll try to get a new patch set uploaded asap. It's not forgotten (I also let Colin know off list because he had said I could push it too), don't worry. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Added glyphs for Kievan Notation (issue 4951062)
LGTM.
Only some minor style nitpicks; you may also wish to change commit's
message (currently it says that there is only one glyph added). You can
modify commit messages using
git rebase -i origin/master
http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf
File mf/feta-kievan.mf (right):
http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf#newcode27
mf/feta-kievan.mf:27: fet_beginchar(kievan quarter (down), d4);
there shold be space between fet_beginchar and ( everywhere in the file
http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf#newcode53
mf/feta-kievan.mf:53:
I think there shouldn't be empty line here.
http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf#newcode78
mf/feta-kievan.mf:78: fill z1{dir -6.9} .. z2 .. z3 z3 .. z4 .. z5
z5 -- z6 z6 .. z7 .. z8 z8{left} .. z9 z9 .. z10 ... {dir
-76.9}cycle;
please break this line (in general lines shouldn't be wider than 80
characters)
http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf#newcode99
mf/feta-kievan.mf:99: fill z2 -- z8 -- z7 -- z12 -- z11 -- z6 -- z5 --
z10 -- z9 -- z4 -- z3 -- z1 -- cycle;
as above
http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf#newcode119
mf/feta-kievan.mf:119: fill z1 -- z2 -- z6 -- z5 -- z9 -- z10 -- z12 --
z11 -- z7 -- z8 -- z4 -- z3 -- z1 -- cycle;
as above, and below the same
http://codereview.appspot.com/4951062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: include lines in breve X-extent (issue 1814) (issue 4931043)
Ian, On 2011/08/30 10:29:42, Ian Hulin (gmail) wrote: Janek, Bertrand posted some review comments here. I think it would be polite in the case of a newer contributor like Bertrand to post some responses one way or another (either don't worry about it, because. . . or nice catch, I'll upload an updated patch set.) You are absolutely right! I had limited access to my e-mail and missed this. Sorry, Bertrand! I have new patch set ready, but i have trouble logging as another user in git-cl (this issue was created by my previous e-mail account). Can you give me some clue? http://codereview.appspot.com/4931043/diff/1/mf/feta-noteheads.mf File mf/feta-noteheads.mf (right): http://codereview.appspot.com/4931043/diff/1/mf/feta-noteheads.mf#newcode168 mf/feta-noteheads.mf:168: gap# := (0.95 - 0.008 * design_size) * stemthick#; On 2011/08/25 15:03:04, Bertrand Bordage wrote: You should save gap, line 161. Done. http://codereview.appspot.com/4931043/diff/1/mf/feta-noteheads.mf#newcode169 mf/feta-noteheads.mf:169: define_pixels (gap); On 2011/08/25 15:03:04, Bertrand Bordage wrote: This should be moved after set_char_box. Done. http://codereview.appspot.com/4931043/diff/1/mf/feta-noteheads.mf#newcode213 mf/feta-noteheads.mf:213: draw_gridline (z1 - (i * (gap + stemthick), 0), On 2011/08/25 15:03:04, Bertrand Bordage wrote: Hmmm... Don't you think (i * (gap + stemthick), 0) has to be written one time instead of four ? I'm not sure what you mean. Are you saying that i should assign (i * (gap + stemthick), 0) to a variable in the for loop? I.e. sth like for i := 0 step 1 until linecount - 1: foobar := (i * (gap + stemthick), 0); draw_gridline (z1 - foobar, z2 - foobar, stemthick); draw_gridline (z3 + foobar, z4 + foobar, stemthick); endfor; ? http://codereview.appspot.com/4931043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories
Graham Percival wrote Monday, September 05, 2011 9:39 PM http://lilypond.org/~graham/gop/gop_11.html I'm happy with this proposal, but the origin/dev branches are not mentioned explicitly. Presumably they remain unchanged? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: include lines in breve X-extent (issue 1814) (issue 4931043)
On Tue, Sep 06, 2011 at 08:54:40AM +, janek.lilyp...@gmail.com wrote: I have new patch set ready, but i have trouble logging as another user in git-cl (this issue was created by my previous e-mail account). Can you give me some clue? Just make a new issue. Follow the instructions in the CG to reset git-cl. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories
On Tue, Sep 06, 2011 at 10:27:25AM +0100, Trevor Daniels wrote: Graham Percival wrote Monday, September 05, 2011 9:39 PM http://lilypond.org/~graham/gop/gop_11.html I'm happy with this proposal, but the origin/dev branches are not mentioned explicitly. Presumably they remain unchanged? Yes, since those are logical branches -- at some point in time the code in dev/* was split away from the code in master. By contrast, the branches I think we should move to a different repository were never split away from master. Unchanged are: master release/unstable lilypond/translation stable/* dev/* cvs/master tarball/master the last two aren't particularly relevant these days, but they don't do any harm. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
include lines in breve X-extent (issue 1814) (issue 4986042)
Reviewers: Bertrand Bordage, Ian Hulin (gmail), Message: New patch set uploaded, two of Bertrand's concerns addressed (i'm not sure what the third one means). this replaces 4931043. http://codereview.appspot.com/4986042/diff/1/mf/feta-noteheads.mf File mf/feta-noteheads.mf (right): http://codereview.appspot.com/4986042/diff/1/mf/feta-noteheads.mf#newcode217 mf/feta-noteheads.mf:217: z4 + (i * (gap + stemthick), 0), On 2011/08/25 15:03:04, Bertrand Bordage wrote: Hmmm... Don't you think (i * (gap + stemthick), 0) has to be written one time instead of four ? I'm not sure what you mean. Are you saying that i should assign (i * (gap + stemthick), 0) to a variable in the for loop? I.e. sth like for i := 0 step 1 until linecount - 1: foobar := (i * (gap + stemthick), 0); draw_gridline (z1 - foobar, z2 - foobar, stemthick); draw_gridline (z3 + foobar, z4 + foobar, stemthick); endfor; ? Description: char box of breve glyphs is widened to include the lines, not only notehead. This will allow Lily to calculate collisions with breves correctly. It shouldn't change how breves are aligned in note columns. Please review this at http://codereview.appspot.com/4986042/ Affected files: M mf/feta-noteheads.mf Index: mf/feta-noteheads.mf diff --git a/mf/feta-noteheads.mf b/mf/feta-noteheads.mf index a58e4bc89a7a6c607a3da1dea2478ecce9b8ba0f..ee5c9457673f5ff2baf3351ec6875c87c40802c9 100644 --- a/mf/feta-noteheads.mf +++ b/mf/feta-noteheads.mf @@ -158,12 +158,16 @@ fi; def draw_brevis (expr linecount, line_thickness_multiplier) = - save stemthick, fudge; + save stemthick, fudge, gap; stemthick# = line_thickness_multiplier * 2 * stafflinethickness#; define_whole_blacker_pixels (stemthick); % Breves of smaller design sizes should have their lines + % farther apart. + gap# := (0.95 - 0.008 * design_size) * stemthick#; + + % Breves of smaller design sizes should have their lines % farther apart (the overlap should be smaller). fudge = hround (blot_diameter * min (max (-0.15, @@ -175,6 +179,12 @@ def draw_brevis (expr linecount, line_thickness_multiplier) = draw_outside_ellipse (1.80, 0, 0.707, 0); undraw_inside_ellipse (1.30, 125, 0.68, 2 stafflinethickness#); + set_char_box (stemthick# * linecount + gap# * (linecount - 1), + width# + stemthick# * linecount + gap# * (linecount - 1), + noteheight# / 2, + noteheight# / 2); + + define_pixels (gap); pickup pencircle scaled stemthick; % Breves of smaller design sizes should have their lines longer. @@ -194,20 +204,17 @@ def draw_brevis (expr linecount, line_thickness_multiplier) = rt x1 - fudge = 0; x1 = x2; - fudge + lft x3 = w; + fudge + lft x3 = width; x4 = x3; y4 = y2; y3 = y1; - % Breves of smaller design sizes should have their lines - % farther apart. - line_distance := (1.95 - 0.008 * design_size) * stemthick; for i := 0 step 1 until linecount - 1: - draw_gridline (z1 - (i * line_distance, 0), - z2 - (i * line_distance, 0), + draw_gridline (z1 - (i * (gap + stemthick), 0), + z2 - (i * (gap + stemthick), 0), stemthick); - draw_gridline (z3 + (i * line_distance, 0), - z4 + (i * line_distance, 0), + draw_gridline (z3 + (i * (gap + stemthick), 0), + z4 + (i * (gap + stemthick), 0), stemthick); endfor; enddef; ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: please push patches
Hello )-Original Message- )From: Neil Puttock [mailto:n.putt...@gmail.com] )Sent: 05 September 2011 16:44 )To: Graham Percival )Cc: k-ohara5...@oco.net; Janek Warchoł; James Lowe; lilypond- )de...@gnu.org )Subject: Re: please push patches ) )On 4 September 2011 20:39, Graham Percival graham@percival- )music.ca wrote: ) Since Colin is off on holiday in the best place on earth (i.e. ) Western Canada), I'll send the reminder. ) ) All the above people: you have patches that should be pushed. ) )http://code.google.com/p/lilypond/issues/list?can=2q=label:patchsort ) =patch no particular rush; I just didn't want you to forget. ) )Sorry, will try to sort out the fermata fix today or tomorrow. ) )I have to say I'm disappointed nobody has commented on the `accidental )styles as context modifications' patch. I really would like some feedback )first. ) Pass make and reg test ;) James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: GOP-PROP 11: git repositories
-Original Message- From: lilypond-devel-bounces+mail=philholmes@gnu.org [mailto:lilypond-devel-bounces+mail=philholmes@gnu.org] On Behalf Of Trevor Daniels Sent: 06 September 2011 10:27 To: Graham Percival; lilypond-devel@gnu.org Subject: Re: GOP-PROP 11: git repositories Graham Percival wrote Monday, September 05, 2011 9:39 PM http://lilypond.org/~graham/gop/gop_11.html I'm happy with this proposal, but the origin/dev branches are not mentioned explicitly. Presumably they remain unchanged? Trevor How easy is it to switch between the various git repositories? Would we update lilygit, or reserve use of the new repositories for those who had started to use terminal? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories
Am Tuesday, 6. September 2011, 15:45:25 schrieb Phil Holmes: How easy is it to switch between the various git repositories? It's really simple: git remote set-url origin [new-URL-comes-here] Or if you want to keep the old, simply create a new remote: git remote add newserver [new-URL-comes-here] You can then push/pull/fetch from newserver just like you did on the main lilypond server (named origin). E.g. git push newserver master or git fetch newserver After all, that's one of the main objectives of distributed versioning systems like git: They are not tied to one particular server. For example, I'm working on lilypond on my home laptop and my office PC. I'm creating branches on both, committing stuff on both and the fetch and push regurlarly between those two computers (i.e. I have more remotes than origin, and I do git fetch -- all). That way, I always have the state of the other machine readily available on the machine I'm working on.. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories
On Tue, Sep 06, 2011 at 02:45:25PM +0100, Phil Holmes wrote: How easy is it to switch between the various git repositories? Would we update lilygit, or reserve use of the new repositories for those who had started to use terminal? It's not hard for command-line people. We would not update lilygit, because nothing in those other repositories are things that normal contributors would care about. The only possible exception is lilypad, but if somebody is sufficiently technically skilled that they could hope to make a meaningful contribution to lilypad, then they are also sufficiently technically skilled to spend 30 minutes reading a git tutorial. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: GOP-PROP 11: git repositories
-Original Message- From: Graham Percival [mailto:gra...@percival-music.ca] Sent: 06 September 2011 15:26 To: Phil Holmes Cc: 'Trevor Daniels'; lilypond-devel@gnu.org Subject: Re: GOP-PROP 11: git repositories On Tue, Sep 06, 2011 at 02:45:25PM +0100, Phil Holmes wrote: How easy is it to switch between the various git repositories? Would we update lilygit, or reserve use of the new repositories for those who had started to use terminal? It's not hard for command-line people. We would not update lilygit, because nothing in those other repositories are things that normal contributors would care about. The only possible exception is lilypad, but if somebody is sufficiently technically skilled that they could hope to make a meaningful contribution to lilypad, then they are also sufficiently technically skilled to spend 30 minutes reading a git tutorial. Cheers, - Graham I quickly gave up with lilypad. I couldn't see it gave me an advantage over Notepad and then started using a paid-for editor with parentesis matching, etc. I seem to remember that it didn't do things like find and replace? What's its advantage over notepad? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: include lines in breve X-extent (issue 1814) (issue 4931043)
On 2011/09/06 08:54:40, janek wrote: I'm not sure what you mean. Are you saying that i should assign (i * (gap + stemthick), 0) to a variable in the for loop? I.e. sth like for i := 0 step 1 until linecount - 1: foobar := (i * (gap + stemthick), 0); draw_gridline (z1 - foobar, z2 - foobar, stemthick); draw_gridline (z3 + foobar, z4 + foobar, stemthick); endfor; ? Yes, that would be cleaner and easier to understand. http://codereview.appspot.com/4931043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make accidental styles available as context mods. (issue 4819064)
Reinhold Kainhofer reinh...@kainhofer.com writes:
Am Montag, 5. September 2011, 23:02:11 schrieb David Kastrup:
#{..#} _is_ a direct Scheme construct interpreted at _read_ time in the
Scheme reader. It is enabled in scm/parser-ly-from-scheme.scm with the
line (read-hash-extend #\{ read-lily-expression).
Within Lilypond, there is no place where you can read Scheme source but
not a #{...#} construct except in the load order before
scm/parser-ly-from-scheme.scm.
Actually, what I meant was that sometimes you are writing a scheme
function, and you are constructing context mods in scheme. If you
already have a list of context mod entries, how can you create the
context mod?
(let* ((mod-entries (map create-mod-from-something your-list)))
#{
\with {
% What comes here to turn the scheme list mod-entries into
% context mod???
}
#})
(let ((mod-entries (map create-mod-from-something your-list)))
(reduce-right (lambda (a b) #{ \with { $b $a } #}) #{\with{}#} your-list))
Also, this creates a snippet in lilypon syntax from an existing scheme
list, just to have it parsed and the exact list created again by the
parser. So, that's not very efficient.
I actually did not realize that evaluating the expression ran the parser
at runtime (as opposed to meddling with $-replacements happening at
compile time).
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add some polyphonically directed grobs (issue 4387046)
Ok, DynamicText and DynamicLineSpanner should be removed. But what about the others? * Simple trill is directed (as a Script), so TrillSpanner logically has to be directed. * Slurs, Ties and TupletBrackets are also directed, so I don't see any reason for LigatureBrackets to behave differently. * AccidentalSuggestion in polyphony leads to mistakes if it isn't directed. Bertrand http://codereview.appspot.com/4387046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: GOP-PROP 11: git repositories
-Original Message- From: lilypond-devel-bounces+mail=philholmes@gnu.org [mailto:lilypond-devel-bounces+mail=philholmes@gnu.org] On Behalf Of Trevor Daniels Sent: 06 September 2011 10:27 To: Graham Percival; lilypond-devel@gnu.org Subject: Re: GOP-PROP 11: git repositories Graham Percival wrote Monday, September 05, 2011 9:39 PM http://lilypond.org/~graham/gop/gop_11.html I'm happy with this proposal, but the origin/dev branches are not mentioned explicitly. Presumably they remain unchanged? Trevor Another thought. We've established a standard (that not everyone adopts, but it's still a standard) that the git repository is locally stored in lilypond-git with the build being done in lilypond-git/build. Where would these new repositories be locally stored? -- Phil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories
On Tue, Sep 06, 2011 at 05:45:19PM +0100, Phil Holmes wrote: Another thought. We've established a standard (that not everyone adopts, but it's still a standard) that the git repository is locally stored in lilypond-git with the build being done in lilypond-git/build. Where would these new repositories be locally stored? Wherever they want. We currently have an average of 3 commits per *year* to those branches (and the things they would replace). If they were easier to find, it might go up to 10 commits per year, but I really doubt that it'd go higher. The only kind of person who's interested in those other repositories will have their own favorite directory layout anyway (like me; all my source repositories go under $HOME/src/) so they'd ignore any recommendation anyway. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: GOP-PROP 11: git repositories
-Original Message- From: Graham Percival [mailto:gra...@percival-music.ca] Sent: 06 September 2011 17:49 To: Phil Holmes Cc: 'Trevor Daniels'; lilypond-devel@gnu.org Subject: Re: GOP-PROP 11: git repositories On Tue, Sep 06, 2011 at 05:45:19PM +0100, Phil Holmes wrote: Another thought. We've established a standard (that not everyone adopts, but it's still a standard) that the git repository is locally stored in lilypond-git with the build being done in lilypond-git/build. Where would these new repositories be locally stored? Wherever they want. We currently have an average of 3 commits per *year* to those branches (and the things they would replace). If they were easier to find, it might go up to 10 commits per year, but I really doubt that it'd go higher. The only kind of person who's interested in those other repositories will have their own favorite directory layout anyway (like me; all my source repositories go under $HOME/src/) so they'd ignore any recommendation anyway. Wouldn't it be better to standardise them so that the doc and website builds can copy them using standard scripts? -- Phil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: include lines in breve X-extent (issue 1814) (issue 4931043)
Reviewers: janek, Bertrand Bordage, MikeSol, J_lowe, Ian Hulin (gmail), graham_percival-music.ca, Message: On 2011/09/06 16:26:40, Bertrand Bordage wrote: On 2011/09/06 08:54:40, janek wrote: I'm not sure what you mean. Are you saying that i should assign (i * (gap + stemthick), 0) to a variable in the for loop? I.e. sth like for i := 0 step 1 until linecount - 1: foobar := (i * (gap + stemthick), 0); draw_gridline (z1 - foobar, z2 - foobar, stemthick); draw_gridline (z3 + foobar, z4 + foobar, stemthick); endfor; ? Yes, that would be cleaner and easier to understand. Done (http://codereview.appspot.com/4986042/) Description: include lines in breve X-extent (issue 1814) char box of breve glyphs is widened to include the lines, not only notehead. This will allow Lily to calculate collisions with breves correctly. It shouldn't change how breves are aligned in note columns. Please review this at http://codereview.appspot.com/4931043/ Affected files: M mf/feta-noteheads.mf Index: mf/feta-noteheads.mf diff --git a/mf/feta-noteheads.mf b/mf/feta-noteheads.mf index a58e4bc89a7a6c607a3da1dea2478ecce9b8ba0f..1c208b651d9a248bb48b10deb05c3ff63d4c11d5 100644 --- a/mf/feta-noteheads.mf +++ b/mf/feta-noteheads.mf @@ -164,6 +164,11 @@ def draw_brevis (expr linecount, line_thickness_multiplier) = define_whole_blacker_pixels (stemthick); % Breves of smaller design sizes should have their lines + % farther apart. + gap# := (0.95 - 0.008 * design_size) * stemthick#; + define_pixels (gap); + + % Breves of smaller design sizes should have their lines % farther apart (the overlap should be smaller). fudge = hround (blot_diameter * min (max (-0.15, @@ -175,6 +180,11 @@ def draw_brevis (expr linecount, line_thickness_multiplier) = draw_outside_ellipse (1.80, 0, 0.707, 0); undraw_inside_ellipse (1.30, 125, 0.68, 2 stafflinethickness#); + set_char_box (stemthick# * linecount + gap# * (linecount - 1), + width# + stemthick# * linecount + gap# * (linecount - 1), + noteheight# / 2, + noteheight# / 2); + pickup pencircle scaled stemthick; % Breves of smaller design sizes should have their lines longer. @@ -194,20 +204,17 @@ def draw_brevis (expr linecount, line_thickness_multiplier) = rt x1 - fudge = 0; x1 = x2; - fudge + lft x3 = w; + fudge + lft x3 = width; x4 = x3; y4 = y2; y3 = y1; - % Breves of smaller design sizes should have their lines - % farther apart. - line_distance := (1.95 - 0.008 * design_size) * stemthick; for i := 0 step 1 until linecount - 1: - draw_gridline (z1 - (i * line_distance, 0), - z2 - (i * line_distance, 0), + draw_gridline (z1 - (i * (gap + stemthick), 0), + z2 - (i * (gap + stemthick), 0), stemthick); - draw_gridline (z3 + (i * line_distance, 0), - z4 + (i * line_distance, 0), + draw_gridline (z3 + (i * (gap + stemthick), 0), + z4 + (i * (gap + stemthick), 0), stemthick); endfor; enddef; ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories
On Tue, Sep 06, 2011 at 06:14:57PM +0100, Phil Holmes wrote: The only kind of person who's interested in those other repositories will have their own favorite directory layout anyway (like me; all my source repositories go under $HOME/src/) so they'd ignore any recommendation anyway. Wouldn't it be better to standardise them so that the doc and website builds can copy them using standard scripts? hmm, good point. What about just using environment variables, $LILYPOND_GIT and $LILYPOND_MEDIA_GIT, then telling the user to set up these variables by themselves? (potentially after googling for help) That feels like a more unix-y solution to me. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: GOP-PROP 11: git repositories
-Original Message- From: Graham Percival [mailto:gra...@percival-music.ca] Sent: 06 September 2011 18:20 To: Phil Holmes Cc: 'Trevor Daniels'; lilypond-devel@gnu.org Subject: Re: GOP-PROP 11: git repositories On Tue, Sep 06, 2011 at 06:14:57PM +0100, Phil Holmes wrote: The only kind of person who's interested in those other repositories will have their own favorite directory layout anyway (like me; all my source repositories go under $HOME/src/) so they'd ignore any recommendation anyway. Wouldn't it be better to standardise them so that the doc and website builds can copy them using standard scripts? hmm, good point. What about just using environment variables, $LILYPOND_GIT and $LILYPOND_MEDIA_GIT, then telling the user to set up these variables by themselves? (potentially after googling for help) That feels like a more unix-y solution to me. :) Surely it's better to put them in My Documents\lily\media, etc. :-) I'm reasonably easy, providing there's some standard way of accessing the files. It just seems to me that if you're going to say you must set up a variable called LILYPOND_GIT pointing to your repository you might as well say To use standard build methods, you must put the repositories in these directories. -- Phil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories
On Tue, Sep 06, 2011 at 06:25:34PM +0100, Phil Holmes wrote: -Original Message- From: Graham Percival [mailto:gra...@percival-music.ca] What about just using environment variables, $LILYPOND_GIT and $LILYPOND_MEDIA_GIT, then telling the user to set up these variables by themselves? (potentially after googling for help) That feels like a more unix-y solution to me. :) Surely it's better to put them in My Documents\lily\media, etc. :-) I'm reasonably easy, providing there's some standard way of accessing the files. It just seems to me that if you're going to say you must set up a variable called LILYPOND_GIT pointing to your repository you might as well say To use standard build methods, you must put the repositories in these directories. Honest answer? Because I want to use the standard build methods, but I'm not going to change my directory structure. Sure, there might be other people like me who would be spectactularly unimpressed with a project that insisted on hard-coding their directory paths and we don't want to turn away people like that, but really the biggest reason is my own convenience. On that note, I wonder if it would be worth standardizing everything on LILYPOND_GIT instead of $HOME/lilypond-git. There would be no change to lilydev people, since we'd set that up for them, so it's just a matter of changing all the scripts+docs appropriately. Then I wouldn't need the weird symlink on the webserver and more experienced developers can put their lilypond git repo wherever they want. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: GOP-PROP 11: git repositories
-Original Message- From: Graham Percival [mailto:gra...@percival-music.ca] Sent: 06 September 2011 18:38 To: Phil Holmes Cc: 'Trevor Daniels'; lilypond-devel@gnu.org Subject: Re: GOP-PROP 11: git repositories On Tue, Sep 06, 2011 at 06:25:34PM +0100, Phil Holmes wrote: -Original Message- From: Graham Percival [mailto:gra...@percival-music.ca] What about just using environment variables, $LILYPOND_GIT and $LILYPOND_MEDIA_GIT, then telling the user to set up these variables by themselves? (potentially after googling for help) That feels like a more unix-y solution to me. :) Surely it's better to put them in My Documents\lily\media, etc. :-) I'm reasonably easy, providing there's some standard way of accessing the files. It just seems to me that if you're going to say you must set up a variable called LILYPOND_GIT pointing to your repository you might as well say To use standard build methods, you must put the repositories in these directories. Honest answer? Because I want to use the standard build methods, but I'm not going to change my directory structure. Sure, there might be other people like me who would be spectactularly unimpressed with a project that insisted on hard-coding their directory paths and we don't want to turn away people like that, but really the biggest reason is my own convenience. On that note, I wonder if it would be worth standardizing everything on LILYPOND_GIT instead of $HOME/lilypond-git. There would be no change to lilydev people, since we'd set that up for them, so it's just a matter of changing all the scripts+docs appropriately. Then I wouldn't need the weird symlink on the webserver and more experienced developers can put their lilypond git repo wherever they want. LGTM. Can you add a note to this effect (i.e. the use of the variables and their names) to the PROP? -- Phil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories
Am Dienstag, 6. September 2011, 19:14:57 schrieb Phil Holmes: -Original Message- From: Graham Percival [mailto:gra...@percival-music.ca] The only kind of person who's interested in those other repositories will have their own favorite directory layout anyway (like me; all my source repositories go under $HOME/src/) so they'd ignore any recommendation anyway. Wouldn't it be better to standardise them so that the doc and website builds can copy them using standard scripts? No, the doc and website build MUST NOT depend on anything that is not part of the lilypond git repo. Anything else does not simplify things, but rather complicates the build by one more dependency (which we then also have to check for in the ./configure script, properly document in the instructions, and most importantly also have to regularly update/fetch to keep the main build working)... The idea here is not to split up the current codebase to multiple repositories. Rather, we have some branches in our git repository, which do not have anything to do with the lilypond codebase. The proposal is to move that code out of the lilypond git repository and into their own. Lilypond will not depend on those other repositories at all. cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories
Am Dienstag, 6. September 2011, 19:20:05 schrieb Graham Percival: On Tue, Sep 06, 2011 at 06:14:57PM +0100, Phil Holmes wrote: The only kind of person who's interested in those other repositories will have their own favorite directory layout anyway (like me; all my source repositories go under $HOME/src/) so they'd ignore any recommendation anyway. Wouldn't it be better to standardise them so that the doc and website builds can copy them using standard scripts? hmm, good point. What about just using environment variables, $LILYPOND_GIT and $LILYPOND_MEDIA_GIT, then telling the user to set up these variables by themselves? (potentially after googling for help) That feels like a more unix-y solution to me. :) Wait a second, why would we need those at all? If the codebases are completely separate, one shouldn't depend on the other. And the build already knows the source dir, so we don't need any pointer in an env variable. Or am I misunderstanding something here? What exactly depends on the source being in ~/lilypond-git? Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Kievan square notation in LilyPond
2011/9/5 Aleksandr Andreev aleksandr.andr...@gmail.com: Hi Janek, Please report is these worked for you. If so, i will update Just a thought: if you're editing the documentation, it would be useful to indicate that git-cl pulls up an interface of vim and that to get out of it, you use the standard vim commands. It's not obvious when you're doing for the first time. To the uninitiated, it looks like the script just crashes. I've updated address of git cl repository, but because of what Graham said i didn't write anything about vim. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories
On 9/6/11 11:25 AM, Phil Holmes m...@philholmes.net wrote: -Original Message- From: Graham Percival [mailto:gra...@percival-music.ca] Sent: 06 September 2011 18:20 To: Phil Holmes Cc: 'Trevor Daniels'; lilypond-devel@gnu.org Subject: Re: GOP-PROP 11: git repositories On Tue, Sep 06, 2011 at 06:14:57PM +0100, Phil Holmes wrote: The only kind of person who's interested in those other repositories will have their own favorite directory layout anyway (like me; all my source repositories go under $HOME/src/) so they'd ignore any recommendation anyway. Wouldn't it be better to standardise them so that the doc and website builds can copy them using standard scripts? hmm, good point. What about just using environment variables, $LILYPOND_GIT and $LILYPOND_MEDIA_GIT, then telling the user to set up these variables by themselves? (potentially after googling for help) That feels like a more unix-y solution to me. :) Surely it's better to put them in My Documents\lily\media, etc. :-) I'm reasonably easy, providing there's some standard way of accessing the files. It just seems to me that if you're going to say you must set up a variable called LILYPOND_GIT pointing to your repository you might as well say To use standard build methods, you must put the repositories in these directories. But your last statement forces a particular location. What if on my system I have a conflict with that location? I shouldn't be forced to do it. Currently, I don't use lilypond-git. And I don't do an out-of-tree build (because it doesn't work for me on OS/X, and I don't want to use lilydev, and I don't want to take the time to troubleshoot it). And I'm able to deal with non-standard locations just fine. If you say I must put them where you say, then I lose that flexibility. I'm totally fine with having lilydev set up environment variables with the standard directories. And I'm fine with saying The standard locations are But enforcing the use of standard locations would be a mistake, IMO. Thanks, Carl -- Phil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories
2011/9/6 Carl Sorensen c_soren...@byu.edu: But your last statement forces a particular location. What if on my system I have a conflict with that location? I shouldn't be forced to do it. Currently, I don't use lilypond-git. And I don't do an out-of-tree build (because it doesn't work for me on OS/X, and I don't want to use lilydev, and I don't want to take the time to troubleshoot it). And I'm able to deal with non-standard locations just fine. If you say I must put them where you say, then I lose that flexibility. I'm totally fine with having lilydev set up environment variables with the standard directories. And I'm fine with saying The standard locations are But enforcing the use of standard locations would be a mistake, IMO. +1 cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories
On Tue, Sep 06, 2011 at 08:17:44PM +0200, Reinhold Kainhofer wrote: Am Dienstag, 6. September 2011, 19:20:05 schrieb Graham Percival: What about just using environment variables, $LILYPOND_GIT and $LILYPOND_MEDIA_GIT, then telling the user to set up these variables by themselves? (potentially after googling for help) That feels like a more unix-y solution to me. :) Wait a second, why would we need those at all? If the codebases are completely separate, one shouldn't depend on the other. And the build already knows the source dir, so we don't need any pointer in an env variable. Or am I misunderstanding something here? What exactly depends on the source being in ~/lilypond-git? The trivial example is the ability to copypaste build instructions from the CG, namely: http://lilypond.org/doc/v2.15/Documentation/contributor/compiling-with-lilydev cd ~/lilypond-git/ sh autogen.sh --noconfigure mkdir -p build/ cd build/ ../configure cd ~/lilypond-git/build/ make cd ~/lilypond-git/build/ make make doc Also, the lily-git.tcl script needs to know where the git repository is; we do *not* want to require that this script is run from inside the source directory. Switching to the web-media repository now: A more sophisticated example, and one which pretty much only affects me and maybe 2 or 3 other people, is the ability to recreate the website exactly as it is on lilypond.org. You can create a website with images by doing make doc make website but that's not how we do stuff on the webserver -- we can't compile lilypond on there. So instead, I compile images on my computer and upload it once or twice a year. Skim these instructions: http://lilypond.org/doc/v2.15/Documentation/contributor/uploading-and-security I want to enable anybody to test something with the exact same setup as the website; instead of me running rsync myself, I want to have a repository for those images. Then (in theory) anybody can update the example images, instead of requiring my personal attention. We also (currently) have some material which is *only* on the website, like the PDF publications (Erik's thesis, Han-Wen and Jan's papers, hopefully Mike's ICMC 2011 paper, etc). It doesn't make sense to put them in the main lilypond git repo, but I'd like to have them in a repository somewhere. That's something else to dump into the web-media repository. I suppose that somebody could make the case that those pdf files, and any other web media which is not compiled directly from lilypond git, really must be in the main lilypond git repository. I have some amount of sympathy for this attitude, but I think it's going overboard. I'm not opposed to an optional --with-web-media-dir= option to ../configure, though. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a site search to website and improves doc search (issue 4894053)
2011/8/26 percival.music...@gmail.com: I have grave doubts about adding a second search box. 1) it makes the top bar uncomfortably squashed in my default web browser window 2) it requires users to choose which type of search they want to do. #1 isn't about me forcing my desktop browser preferences on anybody, but rather I'm making the point that almost all other websites work well on my desktop. I think we should be very cautious about making lilypond.org less accessible than the average websote. (or perhaps I should specify average geek website, since I'm sure that certain other genres of websites are much less accessible than places that I visit) Do we have any compelling evidence that we _need_ to separate these searches? Didn't the previous system just search the website and stable docs; wasn't that sufficient? Also, IIRC there was a suggestion that we search for something like site:lilypond.org/Documentation/v2.14/ instead of adding +2.14. Am I misremembering / would that work / etc? What about searching all docs and website by default, but adding something like advanced search where one can set what he wants to search? If not, i guess that searching stable docs + website would be ok (if it's possible). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 11: git repositories
Janek Warchoł wrote Tuesday, September 06, 2011 8:22 PM 2011/9/6 Carl Sorensen c_soren...@byu.edu: But your last statement forces a particular location. What if on my system I have a conflict with that location? I shouldn't be forced to do it. Currently, I don't use lilypond-git. And I don't do an out-of-tree build (because it doesn't work for me on OS/X, and I don't want to use lilydev, and I don't want to take the time to troubleshoot it). And I'm able to deal with non-standard locations just fine. If you say I must put them where you say, then I lose that flexibility. I'm totally fine with having lilydev set up environment variables with the standard directories. And I'm fine with saying The standard locations are But enforcing the use of standard locations would be a mistake, IMO. +1 +2 Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
