Re: Improves some parmesan noteheads. (issue 4639065)
hi Bertrand, I am a total ligature newbie. But I see some stemmed notes in input/regression/mensural-ligatures.ly . initial and middle stems are drawn separately (see later if-blocks of MLP_STEM and add-join), final ones are part of a longa notehead. Of course, I agree that there's a bug. I fixed it in a new patch set. looks good and clever, but I can't actually test it now; perhaps tonight I'll have the time. I hope you've checked the regtests. thanks, p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change longas similarly to how breves were changed (issue 4962072)
Mostly LGTM, apart from one calculation you do four times. Do it once once and save as a variable and use that. Cheers, Ian http://codereview.appspot.com/4962072/diff/1/mf/feta-noteheads.mf File mf/feta-noteheads.mf (right): http://codereview.appspot.com/4962072/diff/1/mf/feta-noteheads.mf#newcode120 mf/feta-noteheads.mf:120: foobar = quanted_line_length * staff_space; % because you use 'quanted_line_length * staff_space' four times in the code below http://codereview.appspot.com/4962072/diff/1/mf/feta-noteheads.mf#newcode123 mf/feta-noteheads.mf:123: top y2 = quanted_line_length * staff_space; bot y1 = -foobar; top y2 = foobar; % see comment above http://codereview.appspot.com/4962072/diff/1/mf/feta-noteheads.mf#newcode133 mf/feta-noteheads.mf:133: top y2 = quanted_line_length * staff_space; top y2 = foobar; % see comment above http://codereview.appspot.com/4962072/diff/1/mf/feta-noteheads.mf#newcode140 mf/feta-noteheads.mf:140: bot y3 = -quanted_line_length * staff_space; bot y3 = -foobar; % see comment above http://codereview.appspot.com/4962072/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Several fixes for annotate-spacing. (issue 4950071)
http://codereview.appspot.com/4950071/diff/1/lily/page-layout-problem-scheme.cc
File lily/page-layout-problem-scheme.cc (right):
http://codereview.appspot.com/4950071/diff/1/lily/page-layout-problem-scheme.cc#newcode26
lily/page-layout-problem-scheme.cc:26: Return the spacing spec going
between the two given grobs.)
between the two given grobs @var{from-scm} and @var{to-scm}.
http://codereview.appspot.com/4950071/diff/1/lily/page-layout-problem-scheme.cc#newcode28
lily/page-layout-problem-scheme.cc:28: LY_ASSERT_TYPE (unsmob_grob,
from_scm, 1);
LY_ASSERT_SMOB
http://codereview.appspot.com/4950071/diff/1/lily/page-layout-problem-scheme.cc#newcode29
lily/page-layout-problem-scheme.cc:29: LY_ASSERT_TYPE (unsmob_grob,
to_scm, 2);
LY_ASSERT_SMOB
http://codereview.appspot.com/4950071/diff/1/lily/skyline.cc
File lily/skyline.cc (right):
http://codereview.appspot.com/4950071/diff/1/lily/skyline.cc#newcode681
lily/skyline.cc:681: MAKE_SCHEME_CALLBACK (Skyline, get_touching_point,
3)
shouldn't this be
MAKE_SCHEME_CALLBACK_WITH_OPTARGS ?
http://codereview.appspot.com/4950071/diff/1/lily/skyline.cc#newcode699
lily/skyline.cc:699: MAKE_SCHEME_CALLBACK (Skyline, get_distance, 2)
MAKE_SCHEME_CALLBACK_WITH_OPTARGS ?
http://codereview.appspot.com/4950071/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: in what unit is shift_amount measured? (preparing fix for 1546)
2011/9/12 Janek Warchoł janek.lilyp...@gmail.com: Hi, i'm pretty confused about how note columns shift is measured (line 277 and following in note-collision.cc). I tried modifying the values there, but the results were quite unexpected; i tried to trace in what unit is shift_amount measured but to no avail. Could you enlighten me? (my idea to fix 1546 is to include X-extent of the left note column in shift_amount). see Note_collision_interface::calc_positioning_done (SCM smob); it's width of the notehead of clashgroup 0. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change longas similarly to how breves were changed (issue 4962072)
LGTM, with the same comment. http://codereview.appspot.com/4962072/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP-PROP 12: keep master in ready-to-release state
I decided to bring this proposal forward earlier than initially planned. http://lilypond.org/~graham/gop/gop_12.html ** Proposal summary Let’s keep git master in ready-to-release state all the time. In particular, assume that git master could become the next major stable release at any time. If that makes you pause and wonder if you should really push a particular patch (because it would leave something hanging or unfinished), then put that on a separate branch and/or upload to rietveld instead of pushing to master. In addition, modifications which change a lot of output (such as fonts or spacing tweaks) could be “saved up” and applied in a special release which only contains those. ** Rationale Git is a wonderful tool for source handling, but we’re only scratching the surface of what it can do. It might be good to have all active development working on separate branches. This could reduce the pain of git master getting broken from time to time – if everybody worked on separate branches, and those branches were only pulled to master when it compiled correctly, then master would never be broken! In theory, at least. ** Pain of learning git This proposal would require that all main developers have more than basic familiarity with git, but I think there’s enough help out there – I’m particularly impressed by the tutorials on http://github.com. More discussion about the workflow here: https://lists.gnu.org/archive/html/lilypond-devel/2011-09/msg00185.html ** Proposal details Beginning Frogs: no change. They can’t push to master anyway; the Frog Meister will make sure that each change is complete before pushing to master. Advanced frogs attempting huge changes: we’ll sort something out, quite possibly using a fork on github. (seemed to work here: https://github.com/aspiers/lilypond) Developers doing small fixes: no change. Developers doing medium-large fixes: examples include beam collisions, music function rewriting, Flag grobs, etc. All this work should go on separate branches (e.g. dev/flag-grob, dev/scheme-music-functions). Once the code is merged, the branch should be removed. People can still use dev/myname instead, but I think that naming these branches after the feature (or bugfix) will be more clear. ** “font” release The existance of massive-change patches is problematic; a tiny modification to some font can cause almost every regtest to show a change. We could consider saving up those patches, then having a release which only includes those patches. A cursory examination should suffice to see that nothing has broken. At the current rate of releases and patches, I’m envisioning having a font release once every two months. This would require that those patches be stored in a separate branch and only merged with master at the appropriate time. ** Implementation notes None yet. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
On 2011/09/12 22:37:05, janek wrote: i've looked at latest screenshot attached to tracker issue and... wow! It looks really great! Thanks a lot :) http://codereview.appspot.com/4639065/diff/13002/ly/engraver-init.ly#newcode1063 ly/engraver-init.ly:1063: \override Stem #'thickness = #2 I'd make them just a bit thinner, perhaps 1.8. I think that 2 might get too thick with smaller font-size (as font-size decreases, the relative thickness increases). You're right, I'll do that. Do you want to make a patch that sets some other parameters for the PetrucciStaff? http://codereview.appspot.com/4639065/diff/13002/mf/parmesan-noteheads.mf#newcode272 mf/parmesan-noteheads.mf:272: nm_red_holeheight := 2.5 linethickness; I'd make this 3 linethickness. That's what I tried at first, but this strangely looks more readable with 2.5. But I haven't yet compared printed results of different sizes, so you're maybe right. http://codereview.appspot.com/4639065/diff/13002/mf/parmesan-noteheads.mf#newcode329 mf/parmesan-noteheads.mf:329: nm_width := staff_space#; if i'm not mistaken and these are the height and width of half and quarter noteheads, i'd make them very slightly bigger - something like nm_height := 1.1 noteheight#; 329 nm_width := 1.05 staff_space#; Do you know what neomensural and mensural styles are inspired of? I always thought these notes were tiny, but it's maybe intended. As I am not an expert, I kept the shapes as is, but a rebuild would be great since we could get rid of draw_diamond_head (and finally have good ancient fonts). Anyway, the next steps will be (in order) to redesign the ancient rests, accidentals, clefs, time signatures and flags. Do I count you in? Bertrand http://codereview.appspot.com/4639065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: MusicXML: fix case when some elements have a staff number, while others don't (issue 4991044)
LGTM. I think this could have been pushed directly. http://codereview.appspot.com/4991044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
On 2011/09/12 22:37:05, janek wrote: i've looked at latest screenshot attached to tracker issue and... wow! It looks really great! Thanks a lot :) http://codereview.appspot.com/4639065/diff/13002/ly/engraver-init.ly#newcode1063 ly/engraver-init.ly:1063: \override Stem #'thickness = #2 I'd make them just a bit thinner, perhaps 1.8. I think that 2 might get too thick with smaller font-size (as font-size decreases, the relative thickness increases). You're right, I'll do that. Do you want to make a patch that sets some other parameters for the PetrucciStaff? http://codereview.appspot.com/4639065/diff/13002/mf/parmesan-noteheads.mf#newcode272 mf/parmesan-noteheads.mf:272: nm_red_holeheight := 2.5 linethickness; I'd make this 3 linethickness. That's what I tried at first, but this strangely looks more readable with 2.5. But I haven't yet compared printed results of different sizes, so you're maybe right. http://codereview.appspot.com/4639065/diff/13002/mf/parmesan-noteheads.mf#newcode329 mf/parmesan-noteheads.mf:329: nm_width := staff_space#; if i'm not mistaken and these are the height and width of half and quarter noteheads, i'd make them very slightly bigger - something like nm_height := 1.1 noteheight#; 329 nm_width := 1.05 staff_space#; Do you know what neomensural and mensural styles are inspired of? I always thought these notes were tiny, but it's maybe intended. As I am not an expert, I kept the shapes as is, but a rebuild would be great since we could get rid of draw_diamond_head (and finally have good ancient fonts). Anyway, the next steps will be (in order) to redesign the ancient rests, accidentals, clefs, time signatures and flags. Do I count you in? Bertrand http://codereview.appspot.com/4639065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
Thought I'd commented on this one but see http://code.google.com/p/lilypond/issues/detail?id=1839#c13 There are the reg test differences. http://codereview.appspot.com/4639065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: 48-hour countdown to 20110914
Hello, On Tue, Sep 13, 2011 at 4:56 AM, Colin Campbell c...@shaw.ca wrote: For 22:00 MDT Wednesday, September 14 Issue 1873: Added glyphs for Kievan Notation - R 4951062 This has been set back to review after some comments today. Regards -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
Thought I'd commented on this one but see http://code.google.com/p/lilypond/issues/detail?id=1839#c13 There are the reg test differences. http://codereview.appspot.com/4639065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: 48-hour countdown to 20110914
2011/9/13 Peekay Ex pkx1...@gmail.com: Hello, On Tue, Sep 13, 2011 at 4:56 AM, Colin Campbell c...@shaw.ca wrote: For 22:00 MDT Wednesday, September 14 Issue 1873: Added glyphs for Kievan Notation - R 4951062 This has been set back to review you mean needs_work? after some comments today. I don't see any, are you perhaps referring to another patch? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: 48-hour countdown to 20110914
Hello, 2011/9/13 Janek Warchoł janek.lilyp...@gmail.com: 2011/9/13 Peekay Ex pkx1...@gmail.com: Hello, On Tue, Sep 13, 2011 at 4:56 AM, Colin Campbell c...@shaw.ca wrote: For 22:00 MDT Wednesday, September 14 Issue 1873: Added glyphs for Kievan Notation - R 4951062 This has been set back to review you mean needs_work? I do. Sorry. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change longas similarly to how breves were changed (issue 4962072)
New patch set uploaded. http://codereview.appspot.com/4962072/diff/1/mf/feta-noteheads.mf File mf/feta-noteheads.mf (right): http://codereview.appspot.com/4962072/diff/1/mf/feta-noteheads.mf#newcode120 mf/feta-noteheads.mf:120: On 2011/09/13 08:58:57, Ian Hulin (gmail) wrote: foobar = quanted_line_length * staff_space; % because you use 'quanted_line_length * staff_space' four times in the code below Done. http://codereview.appspot.com/4962072/diff/1/mf/feta-noteheads.mf#newcode123 mf/feta-noteheads.mf:123: top y2 = quanted_line_length * staff_space; On 2011/09/13 08:58:57, Ian Hulin (gmail) wrote: bot y1 = -foobar; top y2 = foobar; % see comment above Done. http://codereview.appspot.com/4962072/diff/1/mf/feta-noteheads.mf#newcode133 mf/feta-noteheads.mf:133: top y2 = quanted_line_length * staff_space; On 2011/09/13 08:58:57, Ian Hulin (gmail) wrote: top y2 = foobar; % see comment above Done. http://codereview.appspot.com/4962072/diff/1/mf/feta-noteheads.mf#newcode140 mf/feta-noteheads.mf:140: bot y3 = -quanted_line_length * staff_space; On 2011/09/13 08:58:57, Ian Hulin (gmail) wrote: bot y3 = -foobar; % see comment above Done. http://codereview.appspot.com/4962072/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses langdefs.py to create language list for create-weblinks-itexi.py (issue 4951047)
- Original Message - From: percival.music...@gmail.com To: philehol...@googlemail.com; jan.nieuwenhui...@gmail.com Cc: lilypond-devel@gnu.org; re...@codereview.appspotmail.com Sent: Monday, September 05, 2011 7:10 PM Subject: Re: Uses langdefs.py to create language list for create-weblinks-itexi.py (issue 4951047) LTGM, not tested, but I'm willing to put it up and just see if anything breaks. My only qualm is that this takes lang.LANGAUGES, instead of defining a WEB_LANGUAGES. At the moment they're the same, but somebody might come in to do a new translation, and we don't want to enable that on the website until it's complete. But I'm content to cross that bridge when we come to it. http://codereview.appspot.com/4951047/ I've reduced the reply-to list, because this is not really a review comment but a request for suggestions. I've got a patch that does this. However, there is an issue I want to check about how it can be done. At present, langdefs is called in 2 ways: from python, by including langdefs.py, and then by using the objects created in the module; and from make, simply by saying something like LANGS = python langdefs.py. The latter syntax is provided for in langdefs because of these lines: if __name__ == '__main__': print ' '.join ([l.code for l in LANGUAGES if l.enabled and l.code != 'en']) The problem is - how to return WEB_LANGS for the web-build, but LANGUAGES for the doc build? My patch does this by using something like this in website.make: WEB_LANGS = python langdefs.py web In other words, using an argument to langdefs. langdefs is modified to check whether it has an argument, and that argument is web and if so it returns WEB_LANGS. I can't think of a better way of doing this, but it seems a bit hacky. Can anyone else propose a better way? Thanks. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
2011/9/13 bordage.bertr...@gmail.com: http://codereview.appspot.com/4639065/diff/13002/ly/engraver-init.ly#newcode1063 ly/engraver-init.ly:1063: \override Stem #'thickness = #2 I'd make them just a bit thinner, perhaps 1.8. I think that 2 might get too thick with smaller font-size (as font-size decreases, the relative thickness increases). You're right, I'll do that. Do you want to make a patch that sets some other parameters for the PetrucciStaff? No, i have little experience with ancient music and therefore i don't have any more ideas what could use some fine-tuning. ...actually, one things comes to my mind: staffline thickness. It may be worth considering to make them a bit thicker. In that case, the tail of longa note should be thickened a bit, too (from 1.3 to 1.4 linethickness?). In fact, they may be thickened even if we don't change PetrucciStaff's linethickness. http://codereview.appspot.com/4639065/diff/13002/mf/parmesan-noteheads.mf#newcode272 mf/parmesan-noteheads.mf:272: nm_red_holeheight := 2.5 linethickness; I'd make this 3 linethickness. That's what I tried at first, but this strangely looks more readable with 2.5. But I haven't yet compared printed results of different sizes, so you're maybe right. That's surprising... I may try to print a test file myself, but i can't promise anything since i don't have good enough printer and therefore would need to go find a print shop first. http://codereview.appspot.com/4639065/diff/13002/mf/parmesan-noteheads.mf#newcode329 mf/parmesan-noteheads.mf:329: nm_width := staff_space#; if these are the height and width of half and quarter noteheads, i'd make them very slightly bigger - something like nm_height := 1.1 noteheight#; nm_width := 1.05 staff_space#; Do you know what neomensural and mensural styles are inspired of? I always thought these notes were tiny, but it's maybe intended. As I am not an expert, I kept the shapes as is, but a rebuild would be great since we could get rid of draw_diamond_head (and finally have good ancient fonts). Well, my suggestion of increasing their size a bit was based on the scanned example you provided. In that example quarter and half noteheads look roughly as big as breve and longa noteheads, while the current version of your patch makes them smaller. Anyway, the next steps will be (in order) to redesign the ancient rests, accidentals, clefs, time signatures and flags. Do I count you in? Yes! doing font stuff can be fun :) James: all regtest differencies seem desired to me. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change longas similarly to how breves were changed (issue 4962072)
LGTM Ian http://codereview.appspot.com/4962072/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses langdefs.py to create language list for create-weblinks-itexi.py (issue 4951047)
On Tue, Sep 13, 2011 at 04:42:16PM +0100, Phil Holmes wrote: The problem is - how to return WEB_LANGS for the web-build, but LANGUAGES for the doc build? My patch does this by using something like this in website.make: WEB_LANGS = python langdefs.py web Um. I was just expecting you to define WEB_LANGS = on line 78 of langdefs.py ? I might have missed something (since nobody actually understands all parts of the build system), but surely that would be sufficient? I must admit that I'm really confused about what we're trying to do here, or how far along that path we've gotten (if at all!). Translators wanting to experiment can just change WEB_LANGS themselves (but not commit that change). No trickery is needed in website.make because that's only ever used for building the website without make doc. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A few remarks concerning \relative
On Tue, Sep 13, 2011 at 01:23:19AM +0200, David Kastrup wrote:
It's tutorial-speak at its best. I don't understand either your
unhappiness nor your displeasure.
The tutorial is not the place for musings or cleverness. The goal
is to get people started writing music with the minimum amount of
fuss. We don't even teach people how to write accidentals in the
tutorial! This is quite deliberate -- the tutorial is only for
the absolute minimum to get started.
This tip should go in @ref{Suggestions for writing files}, and of
course in the Notation reference. If you really think it should
be earlier, we could discuss a rewrite of Learning 2.4.3 Absolute
note names, to be more general (alterate note entry? relative
and absolute modes revisised?) and adding this tip. But I would
like to discuss that patch on Rietveld before it's pushed.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 380: Try to auto-detect cyclic references in header fields (issue 4951073)
have you thought of fixing this generically instead? You could the hare/tortoise algorithm to detect cycles in any markup, and could run that on the entry point (not the recursive function) for evaluating markups to stencils. http://codereview.appspot.com/4951073/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A few remarks concerning \relative
2011/9/13 Graham Percival gra...@percival-music.ca:
On Tue, Sep 13, 2011 at 01:23:19AM +0200, David Kastrup wrote:
It's tutorial-speak at its best. I don't understand either your
unhappiness nor your displeasure.
The tutorial is not the place for musings or cleverness. The goal
is to get people started writing music with the minimum amount of
fuss. We don't even teach people how to write accidentals in the
tutorial! This is quite deliberate -- the tutorial is only for
the absolute minimum to get started.
If by tutorial you mean chapter 1 of Learning Manual, i can agree.
This tip should go in @ref{Suggestions for writing files}, and of
course in the Notation reference. If you really think it should
be earlier, we could discuss a rewrite of Learning 2.4.3 Absolute
note names, to be more general (alterate note entry? relative
and absolute modes revisised?) and adding this tip. But I would
like to discuss that patch on Rietveld before it's pushed.
Sounds reasonable.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 380: Try to auto-detect cyclic references in header fields (issue 4951073)
http://codereview.appspot.com/4951073/diff/3001/scm/define-markup-commands.scm File scm/define-markup-commands.scm (right): http://codereview.appspot.com/4951073/diff/3001/scm/define-markup-commands.scm#newcode1897 scm/define-markup-commands.scm:1897: (interpret-markup layout (cons (list (list symbol `(,property-recursive-markup symbol))) props) m) props is an alist, right? In that case, I think you want (interpret-markup layout (cons (cons symbol `(,...)) props) m) http://codereview.appspot.com/4951073/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: in what unit is shift_amount measured? (preparing fix for 1546)
2011/9/13 Han-Wen Nienhuys hanw...@gmail.com: 2011/9/12 Janek Warchoł janek.lilyp...@gmail.com: i'm pretty confused about how note columns shift is measured (line 277 and following in note-collision.cc). I tried modifying the values there, but the results were quite unexpected; i tried to trace in what unit is shift_amount measured but to no avail. Could you enlighten me? (my idea to fix 1546 is to include X-extent of the left note column in shift_amount). see Note_collision_interface::calc_positioning_done (SCM smob); it's width of the notehead of clashgroup 0. i see something... is it line 387: wid = ... ? I think the problem is precisely that we read the x-extent of clashgroup 0 (the one in the structurally highest voice, i.e. in voiceOne) which doesn't have to be the one that will end up on the left. Hmm... all this looks very complicated, and i think it qualifies for a partial rewrite. I'd say that it should work like this: get the colliding notecolumns (it's notecolumns that the code is working on, isn't it?) decide which goes on the left calculate amount of shift apply this shift (or a user-overridden one) Some more questions to clarify things: how do i know which clashgroup (or whatever else is appropriate) ends on the left? How does shift work - does it only move the column on the right by the shift_amount, or does it try to move both columns, each by half shift_amount? What is amount, amounts and tups? What's a slice and what does it do here? Is Note_collision_interface::calc_positioning_done the top-most function? (i.e. the one that is called from outside - sort of main() - and everything else in note-collision.cc is it's descendant?) When a full collision occurs? Is all ASCII-art correct? I don't see what illustrations on lines 125 and 510 could mean. Sorry for noobish questions, but i'm reading this file for an hour and still don't understand it. It's like a Gordian Knot to me. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A few remarks concerning \relative
Graham Percival gra...@percival-music.ca writes:
On Tue, Sep 13, 2011 at 01:23:19AM +0200, David Kastrup wrote:
It's tutorial-speak at its best. I don't understand either your
unhappiness nor your displeasure.
The tutorial is not the place for musings or cleverness. The goal is
to get people started writing music with the minimum amount of fuss.
I don't think that the minimum amount of fun and curiosity is going to
help the motivation.
This tip should go in @ref{Suggestions for writing files}, and of
course in the Notation reference. If you really think it should be
earlier, we could discuss a rewrite of Learning 2.4.3 Absolute note
names, to be more general (alterate note entry? relative and
absolute modes revisised?) and adding this tip. But I would like to
discuss that patch on Rietveld before it's pushed.
I am not going to put up a patch on Rietveld and am not writing any more
documentation for this. I don't have the resources to put up a fight
for user appeal. It is enough of a chore to make Lilypond useful for
myself. I won't fight an upstream battle for others.
I don't understand your attitude and argument in this respect, and I
don't even want to understand it.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add support for custom ledger positions, using two new staff-symbol properties (issue 4974075)
http://codereview.appspot.com/4974075/diff/1/lily/ledger-line-spanner.cc File lily/ledger-line-spanner.cc (right): http://codereview.appspot.com/4974075/diff/1/lily/ledger-line-spanner.cc#newcode362 lily/ledger-line-spanner.cc:362: ledgers.add_stencil (ledger_line); Since you no longer seem to be using the brew_ledger_lines function, please get rid of it. http://codereview.appspot.com/4974075/diff/1/lily/staff-symbol.cc File lily/staff-symbol.cc (right): http://codereview.appspot.com/4974075/diff/1/lily/staff-symbol.cc#newcode82 lily/staff-symbol.cc:82: int l = line_positions.size (); Could you use a different name? l looks an awful lot like 1... http://codereview.appspot.com/4974075/diff/1/lily/staff-symbol.cc#newcode105 lily/staff-symbol.cc:105: int l = scm_to_int (scm_length (line_positions)); and again... http://codereview.appspot.com/4974075/diff/1/lily/staff-symbol.cc#newcode117 lily/staff-symbol.cc:117: int l = Staff_symbol::line_count (me); ok, this one isn't your fault, but I still think it would be good to change it. http://codereview.appspot.com/4974075/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 12: keep master in ready-to-release state
Graham Percival wrote Tuesday, September 13, 2011 2:49 PM Let’s keep git master in ready-to-release state all the time. In particular, assume that git master could become the next major stable release at any time. If that makes you pause and wonder if you should really push a particular patch (because it would leave something hanging or unfinished), then put that on a separate branch and/or upload to rietveld instead of pushing to master. Hhm. Not sure about ready-to-release-a-stable. I think we need warning when a new stable is to be built. It is inevitable that new code will contain bugs which will only be found when users of development releases run real music through them. This takes time, so I'd prefer to have a period prior to building a stable in which major changes were discouraged. I'd be happy with a target of keeping git master in a state which builds docs and runs reg tests without error. That is, no incomplete patches should be pushed. In addition, modifications which change a lot of output (such as fonts or spacing tweaks) could be “saved up” and applied in a special release which only contains those. Tick Git is a wonderful tool for source handling, but we’re only scratching the surface of what it can do. It might be good to have all active development working on separate branches. This could reduce the pain of git master getting broken from time to time – if everybody worked on separate branches, and those branches were only pulled to master when it compiled correctly, then master would never be broken! In theory, at least. I'm pretty sure most developers do their work in separate branches anyway, albeit on local branches. This proposal would require that all main developers have more than basic familiarity with git, but I think there’s enough help out there – I’m particularly impressed by the tutorials on http://github.com. Again I'm pretty sure all main developers already have a good familiarity with git. Developers doing medium-large fixes: examples include beam collisions, music function rewriting, Flag grobs, etc. All this work should go on separate branches (e.g. dev/flag-grob, dev/scheme-music-functions). Once the code is merged, the branch should be removed. People can still use dev/myname instead, but I think that naming these branches after the feature (or bugfix) will be more clear. This would offer an advantage over Reitveld only if several developers were collaborating on a large set of patches. It is quite easy now for anyone to download a patch from Reitveld to check it compiles, runs the reg tests and builds docs successfully. James already does this for the reg tests. All we need to do is formalise it, so large patches are not pushed to master unless and until James (or whoever is willing to do this work) has given approval. If git itself is to be used I think it would be better to have a single staging branch in which patches could be placed prior to merging into master. The reg tests and doc builds could then be run just once prior to merging, rather than separately on each patch. But I'd prefer we stick with Reitveld and encourage developers to test their patches more thoroughly themselves over any of these proposals. The existance of massive-change patches is problematic; a tiny modification to some font can cause almost every regtest to show a change. We could consider saving up those patches, then having a release which only includes those patches. A cursory examination should suffice to see that nothing has broken. At the current rate of releases and patches, I’m envisioning having a font release once every two months. This would require that those patches be stored in a separate branch and only merged with master at the appropriate time. Tick. It also means we don't get caught out with problems caused by not rebuilding the fonts after such changes, as the need for this would be more clearly signaled than at present. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add support for custom ledger positions, using two new staff-symbol properties (issue 4974075)
http://codereview.appspot.com/4974075/diff/1/lily/ledger-line-spanner.cc File lily/ledger-line-spanner.cc (right): http://codereview.appspot.com/4974075/diff/1/lily/ledger-line-spanner.cc#newcode362 lily/ledger-line-spanner.cc:362: ledgers.add_stencil (ledger_line); On 2011/09/13 21:28:58, joeneeman wrote: Since you no longer seem to be using the brew_ledger_lines function, please get rid of it. Done. It had crossed my mind, but I forgot, thanks for noticing. http://codereview.appspot.com/4974075/diff/1/lily/staff-symbol.cc File lily/staff-symbol.cc (right): http://codereview.appspot.com/4974075/diff/1/lily/staff-symbol.cc#newcode82 lily/staff-symbol.cc:82: int l = line_positions.size (); On 2011/09/13 21:28:58, joeneeman wrote: Could you use a different name? l looks an awful lot like 1... Done. http://codereview.appspot.com/4974075/diff/1/lily/staff-symbol.cc#newcode105 lily/staff-symbol.cc:105: int l = scm_to_int (scm_length (line_positions)); On 2011/09/13 21:28:58, joeneeman wrote: and again... Done. http://codereview.appspot.com/4974075/diff/1/lily/staff-symbol.cc#newcode117 lily/staff-symbol.cc:117: int l = Staff_symbol::line_count (me); On 2011/09/13 21:28:58, joeneeman wrote: ok, this one isn't your fault, but I still think it would be good to change it. Done. Indeed, from here I got the l. Much better now. http://codereview.appspot.com/4974075/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 12: keep master in ready-to-release state
On Wed, Sep 14, 2011 at 12:31:14AM +0100, Trevor Daniels wrote: Graham Percival wrote Tuesday, September 13, 2011 2:49 PM Let’s keep git master in ready-to-release state all the time. In Hhm. Not sure about ready-to-release-a-stable. I think we need warning when a new stable is to be built. It is inevitable that new code will contain bugs which will only be found when users of development releases run real music through them. For the record, I'm not proposing to remove the 7-day waiting period for a release candidate. I'd be happy with a target of keeping git master in a state which builds docs and runs reg tests without error. git master should never be in that state; quite apart from the havoc it causes with inexperienced contributors, it makes git bisect a lot more complicated. This could reduce the pain of git master getting broken from time to time – if everybody worked on separate branches, and those branches were only pulled to master when it compiled correctly, then master would never be broken! In theory, at least. I'm pretty sure most developers do their work in separate branches anyway, albeit on local branches. I'm not at all certain about that -- but the main point is to have remote branches. To take a specific example, Mike and Han-Wen did a lot of debugging of beam collision code in a combination of git master and rietveld patches in early 2011. I am proposing that in the future, work of that scale takes place on a shared branch in the public repository. This proposal would require that all main developers have more than basic familiarity with git, but I think there’s enough help out there – I’m particularly impressed by the tutorials on http://github.com. Again I'm pretty sure all main developers already have a good familiarity with git. Do I count as a main developer? because I don't know enough git to do this stuff. I'm not saying that I can't learn, and if the proposal is accepted I certainly *will* learn. But right now I don't have the familiarity with git to be comfortable with making+merging branches, with only pushing changes from one branch, etc. I'm pretty certain that Janek and Phil are in the same situation. And I wouldn't be surprised if Mike wasn't completely fluent in branches, either. With very few exceptions, we're basically treating git like svn. That's not horrible; lots of great software was written (and is still being written) with svn. But I think git+branches can offer so much more than svn-style git. Developers doing medium-large fixes: examples include beam collisions, music function rewriting, Flag grobs, etc. All this This would offer an advantage over Reitveld only if several developers were collaborating on a large set of patches. Yes. Or if there were a set of patches which required a relatively large number of patches to be in ready for release state. It is quite easy now for anyone to download a patch from Reitveld to check it compiles, runs the reg tests and builds docs successfully. I don't think it's quite easy. I need to find the issue, right-click on the download raw patch, type patch -p1 ~/Downloads/issue-1234.patch, etc. Whereas if that work was done in a separate branch, I'd just type git checkout dev/better-build-system and then I'd have the entire thing -- authors, history, and all. It's not a *huge* pain to get patches from Rietveld, but that system doesn't exactly encourage shared work on features until they're pushed to master. That's what I want to change -- I think there should be more development *away* from master. If git itself is to be used I think it would be better to have a single staging branch in which patches could be placed prior to merging into master. The reg tests and doc builds could then be run just once prior to merging, rather than separately on each patch. This is certainly possible. I could easily automate this process, too. Actually, regardless of where this proposal ends up, I think I'll make that a priority for this week. - 24-hour automatic building of master (make, make test, make doc) - 24-hour automatic building of dev/staging, followed by automatically merging those patches with master I'll treat them as separate stages because people might still push stuff directly to master, and it would be good to catch those problems before trying to build dev/staging. But I'd prefer we stick with Reitveld and encourage developers to test their patches more thoroughly themselves over any of these proposals. We've been saying hey guys, test your patches more for the past couple of months, though. My vague impression is that about 20% of patches fail James' regtest comparison, and 5% fail to even compile the regtests! I'm pessimistic about things improving without a more concrete plan -- I'm reminded of the British police joke (told in North America) about the policeman telling a robber stop! or I shall ask you to stop again!. (joke about their
Re: GOP-PROP 12: keep master in ready-to-release state
Graham Percival graham at percival-music.ca writes: If that makes you pause and wonder if you should really push a particular patch (because it would leave something hanging or unfinished), then put that on a separate branch and/or upload to rietveld instead of pushing to master. I like the Reitveld option, if it means completing the review for the patches that need review even if they leave something hanging, then waiting to push the complete set of patches as a group. Changes and fixes often need a convert-ly rule or documentation change. Generally I don't have a doc change ready for review at the time that I want review on the code (and the one time I did get the docs ready up-front, I was sorry I did). In addition, modifications which change a lot of output (such as fonts or spacing tweaks) could be “saved up” and applied in a special release which only contains those. That presumes, however, that there is someone willing to build that special release. The saving up should be easy. (Notice that my change-everything spacing fixes were pushed within a day of the change-everything adjustment of the G-clef.) Graham Percival graham at percival-music.ca writes: On Wed, Sep 14, 2011 at 12:31:14AM +0100, Trevor Daniels wrote: It is quite easy now for anyone to download a patch from Reitveld to check it compiles, runs the reg tests and builds docs successfully. I don't think it's quite easy. [...] Well, interpret quite easy as something we do anyway so it feels quite easy. Everything else Trevor said sounds wise to me as well. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
hi all, the patch is ok from my point of view. a minor question: the only change in mensural-ligatures.ly is the version bump - is that needed? Do you know what neomensural and mensural styles are inspired of? I believe it uses the shapes of noteheads found in manuscript, but scales them to fit between staff lines like modern noteheads so that they don't collide if used in chords (extremely rare; I've seen them only in cadences with breves or longae, never with the diamond shape). have you seen the facsimiles in the message http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00398.html ? p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
