Re: Various updates to reduce make doc output (issue 5727055)
- Original Message - From: Julien Rioux julien.ri...@gmail.com To: Phil Holmes em...@philholmes.net It seems just not worth it. We _never_ want to check warnings as part of make doc. That's what regression tests are for. -- Phil Holmes I disagree, make -s doc is useful to identify warning messages that need fixing, and the log files are also useful for this. I think that the progress messages are what you should focus on silencing. The warning messages should be either fixed at the source or left in place so that someone eventually decides to fix them at the source. In this particular case, it might be that nobody will ever work to improve midi2ly, but that's not for us to say. Regards, Julien Sorry - I expressed myself badly. I meant that we shouldn't use make doc to check that warnings that we expect to appear do, in fact, continue to appear. We should use make test to check that the correct warnings continue to be output. I agree 100% that make doc _should_ make it easy to find new warnings we were unaware of. The problem with this one is that Lilypond (like Sibelius...) only provides 4 voices to allow notes to avoid colliding on a stave. I haven't delved deeply into midi2ly, but my assumption is that it maps midi channels on a single stave to different voices. The offending midi file has more that 4 channels on a stave and therefore the mapping to 4 voices is never going to work properly - and so midi2ly warns the user. But we don't want to continue to see those warnings on the screen, hence the suppression with -q. I can't see why an interactive user would use -q, so it won't give them a problem. I also don't believe that having another logfile solely to contain the message warning: found more than 5 voices on a staff, expect bad output makes much sense. Hence the way I went. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update roadmap, make and make doc info. (issue 5811043)
LGTM http://codereview.appspot.com/5811043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add regtest directory for svg output (issue 2230). (issue 5815043)
Insofar as I don't fully follow this, LGTM. Have you tested by changing an input file and confirming that the regtest checker picks it up? http://codereview.appspot.com/5815043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Build: Better error handling from build scripts. (issue 5812043)
LGTM http://codereview.appspot.com/5812043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Various updates to reduce make doc output (issue 5727055)
On Wed, Mar 14, 2012 at 9:56 AM, Phil Holmes em...@philholmes.net wrote: - Original Message - From: Julien Rioux julien.ri...@gmail.com To: Phil Holmes em...@philholmes.net It seems just not worth it. We _never_ want to check warnings as part of make doc. That's what regression tests are for. -- Phil Holmes I disagree, make -s doc is useful to identify warning messages that need fixing, and the log files are also useful for this. I think that the progress messages are what you should focus on silencing. The warning messages should be either fixed at the source or left in place so that someone eventually decides to fix them at the source. In this particular case, it might be that nobody will ever work to improve midi2ly, but that's not for us to say. Regards, Julien Sorry - I expressed myself badly. I meant that we shouldn't use make doc to check that warnings that we expect to appear do, in fact, continue to appear. We should use make test to check that the correct warnings continue to be output. I agree 100% that make doc _should_ make it easy to find new warnings we were unaware of. The problem with this one is that Lilypond (like Sibelius...) only provides 4 voices to allow notes to avoid colliding on a stave. I haven't delved deeply into midi2ly, but my assumption is that it maps midi channels on a single stave to different voices. The offending midi file has more that 4 channels on a stave and therefore the mapping to 4 voices is never going to work properly - and so midi2ly warns the user. But we don't want to continue to see those warnings on the screen, hence the suppression with -q. I can't see why an interactive user would use -q, so it won't give them a problem. I also don't believe that having another logfile solely to contain the message warning: found more than 5 voices on a staff, expect bad output makes much sense. Hence the way I went. -- Phil Holmes I'm fine with either 1) Leave the warning there (it's only one line of `make doc' output), or 2) Document in `midi2ly --help' that --quiet also silences warning messages. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
page-count and annotate-spacing in documentation
On Tue, Mar 13, 2012 at 11:59 PM, Jean-Alexis Montignies j...@montignies.info wrote: The documentation is usually well written but I find myself browsing many pages before finding something, even if it's something I know it exists and I already used. For instance for sizes. May be a graphic annotated with spacing value names (for staves, systems, paper...) would be a good summary. What about http://www.lilypond.org/doc/v2.15/Documentation/notation/displaying-spacing ? Do you think it should be moved to another section? And for the page count, I didn't thought of looking in other \paper variables, may be an entry could be in fitting music on fewer pages. I've added an entry similar to the one about system-count. It will be visible on the website when a new version is released. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] Fix mordents and pralltriller in articulate.ly
Should this patch (and the other articulation patch) be put on Rietveld or pushed directly? Janek On Wed, Mar 14, 2012 at 6:11 AM, Peter Chubb pet...@gelato.unsw.edu.au wrote: Mordents should be on-beat, not grace notes. And pralltrillers (half-shakes) are always either 4 alternating notes, or an inverted mordent. There is of course a general problem here in that the way ornaments are realised has changed through the centuries. Even Bach and Clementi disagree! I'm following CPE Bach's `True art of Keyboard Playing' in the interpretation here. To do the job properly we'd have two articulations: \prall and \inverted_mordent and treat them separately for MIDI, but typeset the same glyph. Reported-by: Christopher Maden cr...@maden.org Signed-off-by: Peter Chubb peter.ch...@nicta.com.au diff --git a/ly/articulate.ly b/ly/articulate.ly index 3cd98f4..d2d3b18 100644 --- a/ly/articulate.ly +++ b/ly/articulate.ly @@ -394,7 +394,7 @@ ((string= articname mordent) (loop (cons 1 1) newelements tail (cons 'mordent actions))) ((string= articname prall) - (loop (cons 1 1) newelements tail (cons 'trill actions))) + (loop (cons 1 1) newelements tail (cons 'prall actions))) ((string= articname trill) (loop (cons 1 1) newelements tail (cons 'trill actions))) ((string= articname turn) @@ -516,27 +516,78 @@ ((trill) (ac:trill music)) + ((prall) + ; A pralltriller symbol can either mean an inverted mordent + ; or a half-shake -- a short, two twiddle trill. + ; We implement as a half-shake. + (let* + ((totallength (ly:music-length music)) + (newlen (ly:moment-sub totallength (ly:make-moment 3 32))) + (newdur (ly:make-duration + 0 0 + (ly:moment-main-numerator newlen) + (ly:moment-main-denominator newlen))) + (gracedur (ly:make-duration 5 0 1 1)) + (gracenote (ly:music-deep-copy music)) + (abovenote (ly:music-deep-copy music)) + (mainnote (ly:music-deep-copy music)) + (prall (make-sequential-music (list gracenote abovenote))) + ) + (music-map (lambda (n) + (if (eq? 'NoteEvent (ly:music-property n 'name)) + (set! (ly:music-property n 'duration) gracedur)) + n) + abovenote) + (music-map (lambda (n) + (if (eq? 'NoteEvent (ly:music-property n 'name)) + (set! (ly:music-property n 'duration) gracedur)) + n) + gracenote) + (music-map (lambda (n) + (if (eq? 'NoteEvent (ly:music-property n 'name)) + (set! (ly:music-property n 'duration) newdur)) + n) + mainnote) + + (map (lambda (y) (ac:up y)) + (filter + (lambda (z) (eq? 'NoteEvent (ly:music-property z 'name))) + (ly:music-property abovenote 'elements))) + (make-sequential-music (list abovenote gracenote abovenote mainnote + ((mordent) (let* - ((dur (ly:music-property + ((totaldur (ly:music-property (car (ly:music-property music 'elements)) 'duration)) - (factor (ly:duration-factor dur)) + (dur (ly:duration-length totaldur)) + (newlen (ly:moment-sub dur (ly:make-moment 2 32))) + (newdur (ly:make-duration + (ly:moment-main-numerator newlen) + (ly:moment-main-denominator newlen) + 1 + 1)) (gracenote (ly:music-deep-copy music)) - (mainnote (ly:music-deep-copy music)) (belownote (ly:music-deep-copy music)) + (mainnote (ly:music-deep-copy music)) (mordent (make-sequential-music (list gracenote belownote))) -) + ) (begin (music-map (lambda (n) (if (eq? 'NoteEvent (ly:music-property n 'name)) - (set! (ly:music-property n 'duration)(ly:make-duration 3 0 1 1))) + (set! (ly:music-property n 'duration) + (ly:make-duration 5 0 1 1))) n) mordent) + (music-map (lambda (n) + (if (eq? 'NoteEvent (ly:music-property n 'name)) + (set! (ly:music-property n 'duration) newdur)) + n) + mainnote) (map (lambda (y) (ac:down y)) (filter (lambda (z) (eq? 'NoteEvent (ly:music-property z 'name))) (ly:music-property belownote 'elements))) - (make-sequential-music (list (make-grace-music mordent) mainnote) + (make-sequential-music (list mordent mainnote) ((turn) (let* ((dur (ly:music-property -- Dr Peter Chubb peter.chubb AT nicta.com.au http://www.ssrg.nicta.com.au Software Systems Research
Re: Various updates to reduce make doc output (issue 5727055)
Julien Rioux wrote Wednesday, March 14, 2012 10:37 AM On Wed, Mar 14, 2012 at 9:56 AM, Phil Holmes em...@philholmes.net wrote: - Original Message - From: Julien Rioux julien.ri...@gmail.com To: Phil Holmes em...@philholmes.net The problem with this one is that Lilypond (like Sibelius...) only provides 4 voices to allow notes to avoid colliding on a stave. Not true. See Single-staff polyphony in http://www.lilypond.org/doc/v2.15/Documentation/notation/multiple-voices I'm fine with either 1) Leave the warning there (it's only one line of `make doc' output), or Strongly preferred - hiding this warning would be wrong until it is properly understood. 2) Document in `midi2ly --help' that --quiet also silences warning messages. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
[patch] Fix mordents and pralltriller in articulate.ly
Mordents should be on-beat, not grace notes. And pralltrillers (half-shakes) are always either 4 alternating notes, or an inverted mordent. There is of course a general problem here in that the way ornaments are realised has changed through the centuries. Even Bach and Clementi disagree! I'm following CPE Bach's `True art of Keyboard Playing' in the interpretation here. To do the job properly we'd have two articulations: \prall and \inverted_mordent and treat them separately for MIDI, but typeset the same glyph. Reported-by: Christopher Maden cr...@maden.org Signed-off-by: Peter Chubb peter.ch...@nicta.com.au diff --git a/ly/articulate.ly b/ly/articulate.ly index 3cd98f4..d2d3b18 100644 --- a/ly/articulate.ly +++ b/ly/articulate.ly @@ -394,7 +394,7 @@ ((string= articname mordent) (loop (cons 1 1) newelements tail (cons 'mordent actions))) ((string= articname prall) - (loop (cons 1 1) newelements tail (cons 'trill actions))) + (loop (cons 1 1) newelements tail (cons 'prall actions))) ((string= articname trill) (loop (cons 1 1) newelements tail (cons 'trill actions))) ((string= articname turn) @@ -516,27 +516,78 @@ ((trill) (ac:trill music)) + ((prall) + ; A pralltriller symbol can either mean an inverted mordent + ; or a half-shake -- a short, two twiddle trill. + ; We implement as a half-shake. + (let* +((totallength (ly:music-length music)) + (newlen (ly:moment-sub totallength (ly:make-moment 3 32))) + (newdur (ly:make-duration + 0 0 + (ly:moment-main-numerator newlen) + (ly:moment-main-denominator newlen))) + (gracedur (ly:make-duration 5 0 1 1)) + (gracenote (ly:music-deep-copy music)) + (abovenote (ly:music-deep-copy music)) + (mainnote (ly:music-deep-copy music)) + (prall (make-sequential-music (list gracenote abovenote))) + ) + (music-map (lambda (n) + (if (eq? 'NoteEvent (ly:music-property n 'name)) +(set! (ly:music-property n 'duration) gracedur)) + n) + abovenote) + (music-map (lambda (n) + (if (eq? 'NoteEvent (ly:music-property n 'name)) +(set! (ly:music-property n 'duration) gracedur)) + n) + gracenote) + (music-map (lambda (n) + (if (eq? 'NoteEvent (ly:music-property n 'name)) +(set! (ly:music-property n 'duration) newdur)) + n) + mainnote) + + (map (lambda (y) (ac:up y)) + (filter + (lambda (z) (eq? 'NoteEvent (ly:music-property z 'name))) + (ly:music-property abovenote 'elements))) + (make-sequential-music (list abovenote gracenote abovenote mainnote + ((mordent) (let* -((dur (ly:music-property +((totaldur (ly:music-property (car (ly:music-property music 'elements)) 'duration)) - (factor (ly:duration-factor dur)) + (dur (ly:duration-length totaldur)) + (newlen (ly:moment-sub dur (ly:make-moment 2 32))) + (newdur (ly:make-duration + (ly:moment-main-numerator newlen) + (ly:moment-main-denominator newlen) +1 +1)) (gracenote (ly:music-deep-copy music)) - (mainnote (ly:music-deep-copy music)) (belownote (ly:music-deep-copy music)) + (mainnote (ly:music-deep-copy music)) (mordent (make-sequential-music (list gracenote belownote))) -) + ) (begin (music-map (lambda (n) (if (eq? 'NoteEvent (ly:music-property n 'name)) - (set! (ly:music-property n 'duration)(ly:make-duration 3 0 1 1))) + (set! (ly:music-property n 'duration) +(ly:make-duration 5 0 1 1))) n) mordent) + (music-map (lambda (n) + (if (eq? 'NoteEvent (ly:music-property n 'name)) +(set! (ly:music-property n 'duration) newdur)) + n) + mainnote) (map (lambda (y) (ac:down y)) (filter (lambda (z) (eq? 'NoteEvent (ly:music-property z 'name))) (ly:music-property belownote 'elements))) - (make-sequential-music (list (make-grace-music mordent) mainnote) + (make-sequential-music (list mordent mainnote) ((turn) (let* ((dur (ly:music-property -- Dr Peter Chubb peter.chubb AT nicta.com.au http://www.ssrg.nicta.com.au Software Systems Research Group/NICTA ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] Fix mordents and pralltriller in articulate.ly
Hello, 2012/3/14 Janek Warchoł janek.lilyp...@gmail.com: Should this patch (and the other articulation patch) be put on Rietveld or pushed directly? Janek Does it break 'make'? :P I think this needs to be reviewed just like any other patch should be, why *would* we just push this? Also I saw that a new doc commit was merged this morning by you http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=d11dbf277719c0179c5520154c925839d969a535 I might have missed this but did this have a tracker/patchy test? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] Fix mordents and pralltriller in articulate.ly
On Wed, Mar 14, 2012 at 01:39:11PM +, James wrote: I think this needs to be reviewed just like any other patch should be, why *would* we just push this? Well, I think this one is simple enough to push directly. http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=d11dbf277719c0179c5520154c925839d969a535 I might have missed this but did this have a tracker/patchy test? I think that was also simple enough not to need an individual patchy test. As long as it was pushed to staging and not master, stuff that simple is fine. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Various updates to reduce make doc output (issue 5727055)
Phil Holmes wrote Wednesday, March 14, 2012 12:00 PM From: Trevor Daniels t.dani...@treda.co.uk To: Julien Rioux julien.ri...@gmail.com; Phil Holmes em...@philholmes.net Cc: lilypond-devel@gnu.org; re...@codereview-hr.appspotmail.com Sent: Wednesday, March 14, 2012 11:41 AM Subject: Re: Various updates to reduce make doc output (issue 5727055) Julien Rioux wrote Wednesday, March 14, 2012 10:37 AM On Wed, Mar 14, 2012 at 9:56 AM, Phil Holmes em...@philholmes.net wrote: - Original Message - From: Julien Rioux julien.ri...@gmail.com To: Phil Holmes em...@philholmes.net The problem with this one is that Lilypond (like Sibelius...) only provides 4 voices to allow notes to avoid colliding on a stave. Not true. See Single-staff polyphony in http://www.lilypond.org/doc/v2.15/Documentation/notation/multiple-voices I'm fine with either 1) Leave the warning there (it's only one line of `make doc' output), or Strongly preferred - hiding this warning would be wrong until it is properly understood. I think it is understood. Lilypond has a maximum of 4 voices. The midi file has 5. They won't all fit into the 4 maximum. midi2ly warns the user that the output won't look great. But we know that for this midi file and don't need to be told every time it's compiled. Please keep your replies on the list. Didn't you see what I wrote before? There is no restriction to 4 voices in LilyPond, as is shown in the NR. See Single-staff polyphony in http://www.lilypond.org/doc/v2.15/Documentation/notation/multiple-voices So it seems unlikely this is the cause of the warning, hence it is not understood. So hiding this warning would be wrong. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Various updates to reduce make doc output (issue 5727055)
- Original Message - From: Trevor Daniels t.dani...@treda.co.uk To: Phil Holmes m...@philholmes.net Cc: Lily-Devel List lilypond-devel@gnu.org Sent: Wednesday, March 14, 2012 4:28 PM Subject: Re: Various updates to reduce make doc output (issue 5727055) Phil Holmes wrote Wednesday, March 14, 2012 12:00 PM From: Trevor Daniels t.dani...@treda.co.uk To: Julien Rioux julien.ri...@gmail.com; Phil Holmes em...@philholmes.net Cc: lilypond-devel@gnu.org; re...@codereview-hr.appspotmail.com Sent: Wednesday, March 14, 2012 11:41 AM Subject: Re: Various updates to reduce make doc output (issue 5727055) Julien Rioux wrote Wednesday, March 14, 2012 10:37 AM On Wed, Mar 14, 2012 at 9:56 AM, Phil Holmes em...@philholmes.net wrote: - Original Message - From: Julien Rioux julien.ri...@gmail.com To: Phil Holmes em...@philholmes.net The problem with this one is that Lilypond (like Sibelius...) only provides 4 voices to allow notes to avoid colliding on a stave. Not true. See Single-staff polyphony in http://www.lilypond.org/doc/v2.15/Documentation/notation/multiple-voices I'm fine with either 1) Leave the warning there (it's only one line of `make doc' output), or Strongly preferred - hiding this warning would be wrong until it is properly understood. I think it is understood. Lilypond has a maximum of 4 voices. The midi file has 5. They won't all fit into the 4 maximum. midi2ly warns the user that the output won't look great. But we know that for this midi file and don't need to be told every time it's compiled. Please keep your replies on the list. Apologies. Was in a hurry and had finger trouble. Didn't you see what I wrote before? There is no restriction to 4 voices in LilyPond, as is shown in the NR. See Single-staff polyphony in http://www.lilypond.org/doc/v2.15/Documentation/notation/multiple-voices So it seems unlikely this is the cause of the warning, hence it is not understood. So hiding this warning would be wrong. Trevor I've looked at midi2ly and it uses explicit instantiation of voices, which is what we normally advise. My understanding is that there are only 4 explicit voices - voiceFive does not exist, AFAIK. The warning message comes from midi2ly stating that it has no more explicit voice names left, and therefore layout is likely to be poor. We don't need to see this during make doc. I would have no problem with a request to add an issue suggesting an enhancement to midi2ly that it only uses implicit voices where it encounters more than 4 channels on a track, and therefore to lose the error message completely, but I remain firmly of the opinion that we don't need this warning repeated every time we make doc. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Various updates to reduce make doc output (issue 5727055)
On 3/14/12 11:48 AM, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Trevor Daniels t.dani...@treda.co.uk To: Phil Holmes m...@philholmes.net Cc: Lily-Devel List lilypond-devel@gnu.org Sent: Wednesday, March 14, 2012 4:28 PM Subject: Re: Various updates to reduce make doc output (issue 5727055) Didn't you see what I wrote before? There is no restriction to 4 voices in LilyPond, as is shown in the NR. See Single-staff polyphony in http://www.lilypond.org/doc/v2.15/Documentation/notation/multiple-voices I've looked at midi2ly and it uses explicit instantiation of voices, which is what we normally advise. My understanding is that there are only 4 explicit voices - voiceFive does not exist, AFAIK. The warning message comes from midi2ly stating that it has no more explicit voice names left, and therefore layout is likely to be poor. We don't need to see this during make doc. If I read the snippet correctly (Additional voices to avoid collisions, in NR 1.5.2), there is no limit to the number of voices in LilyPond. But only four voices are defined. In the snippet, voiceFive is defined, before it is used. So it would be nice to have a feature added to midi2ly that would automatically create voiceFive, voiceSix, etc. if needed. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Failed make doc for Patchy
I am not at home but Patchy complained just now. -- Forwarded message -- From: pkx1...@gmail.com Date: 14 March 2012 18:34 Subject: Patchy email Merged staging, now at: c6a925ecd742196979038804b02846faad7f2cc9 Success: ./autogen.sh --noconfigure Success: ../configure --disable-optimising Success: nice make clean -j6 CPU_COUNT=6 Success: nice make -j6 CPU_COUNT=6 Success: nice make test -j6 CPU_COUNT=6 *** FAILED BUILD *** nice make doc -j6 CPU_COUNT=6 Previous good commit: d11dbf277719c0179c5520154c925839d969a535 Current broken commit: c6a925ecd742196979038804b02846faad7f2cc9 -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed make doc for Patchy
James pkx1...@gmail.com writes: I am not at home but Patchy complained just now. -- Forwarded message -- From: pkx1...@gmail.com Date: 14 March 2012 18:34 Subject: Patchy email Merged staging, now at: c6a925ecd742196979038804b02846faad7f2cc9 Success: ./autogen.sh --noconfigure Success: ../configure --disable-optimising Success: nice make clean -j6 CPU_COUNT=6 Success: nice make -j6 CPU_COUNT=6 Success: nice make test -j6 CPU_COUNT=6 *** FAILED BUILD *** nice make doc -j6 CPU_COUNT=6 Previous good commit: d11dbf277719c0179c5520154c925839d969a535 Current broken commit: c6a925ecd742196979038804b02846faad7f2cc9 Documentation has not been touched between master and staging. A change by Carl would have triggered more likely in make test than in make doc. That makes changes from me (or a Heisenbug) most likely. My personal suspect would have been commit 65c8ce914c62117fb61a21237f7dcf80ebb0cc6e Author: David Kastrup d...@gnu.org Date: Sun Mar 11 12:16:52 2012 +0100 Make Score an initial Timing alias to allow for context mods But then I am pretty certain that I actually ran make info on that one to make reasonably sure it did not cause offense. I am taking a look right now. If you have relevant log file data, it might speed things up. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed make doc for Patchy
On Wed, Mar 14, 2012 at 08:16:17PM +0100, David Kastrup wrote: commit 65c8ce914c62117fb61a21237f7dcf80ebb0cc6e Make Score an initial Timing alias to allow for context mods But then I am pretty certain that I actually ran make info on that one to make reasonably sure it did not cause offense. info will check if you can generate the internals reference, i.e. with scm/documentation-generate.scm. It won't call the lilypond binary to produce any output at all. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed make doc for Patchy
Graham Percival gra...@percival-music.ca writes: On Wed, Mar 14, 2012 at 08:16:17PM +0100, David Kastrup wrote: commit 65c8ce914c62117fb61a21237f7dcf80ebb0cc6e Make Score an initial Timing alias to allow for context mods But then I am pretty certain that I actually ran make info on that one to make reasonably sure it did not cause offense. info will check if you can generate the internals reference, i.e. with scm/documentation-generate.scm. It won't call the lilypond binary to produce any output at all. You are wrong. Try it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed make doc for Patchy
On Wed, Mar 14, 2012 at 07:45:39PM +, Graham Percival wrote: info will check if you can generate the internals reference, i.e. with scm/documentation-generate.scm. It won't call the lilypond binary to produce any output at all. No wait, I'm completely wrong. Sorry, I was thinking of make (and makeinfo), not make info. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
font regression build regression
Has anybody else seen a huge slow-down in building fonts? They used to whiz by on my screen in a minute or so, but now it takes about 10 minutes, and more to the point, it involves a massive amount of disk activity. My core2quad desktop couldn't play an mp3 file while building fonts with -j3 ! Might it be building the same font multiple times (with different threads creating and deleting the same temporary files?), or are we generating fonts at twice the resolution of the previous one, or...? It's been a few weeks since I tried building stuff from scratch, which leaves a large window of work on the build system and fonts. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed make doc for Patchy
- Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Wednesday, March 14, 2012 7:16 PM Subject: Re: Failed make doc for Patchy James pkx1...@gmail.com writes: I am not at home but Patchy complained just now. Shall I run patchy and check the logfiles? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: font regression build regression
- Original Message - From: Graham Percival gra...@percival-music.ca To: lilypond-devel@gnu.org Sent: Wednesday, March 14, 2012 7:59 PM Subject: font regression build regression Has anybody else seen a huge slow-down in building fonts? They used to whiz by on my screen in a minute or so, but now it takes about 10 minutes, and more to the point, it involves a massive amount of disk activity. My core2quad desktop couldn't play an mp3 file while building fonts with -j3 ! Might it be building the same font multiple times (with different threads creating and deleting the same temporary files?), or are we generating fonts at twice the resolution of the previous one, or...? It's been a few weeks since I tried building stuff from scratch, which leaves a large window of work on the build system and fonts. Is this with a straight make ? I ran it yesterday and didn't see a slowdown, and I always check the time it takes. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20120315
For 20:00 MST Thursday March 15 Sent at Pi, or as near as I can make it on a 12-hour clock! Enhancement: Issue 2395: Patch: Update roadmap, make and make doc info. - R5811043 Issue 2396: Patch: Build: Better error handling from build scripts - R 5812043 Patch:Issue 2378: Patch: Various updates to reduce make doc output - R 5727055 It occurs to me that folk, who don't share my ADD sense of humour, might get rather tart about the delay in the patch batch, but I was a bit hesitant about putting such recent patches onto the countdown, so many thanks to Phil, Julien and Trevor for their comments. Cheers, Colin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed make doc for Patchy
Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Wednesday, March 14, 2012 7:16 PM Subject: Re: Failed make doc for Patchy James pkx1...@gmail.com writes: I am not at home but Patchy complained just now. Shall I run patchy and check the logfiles? I am currently running make doc, but it does not look like it is going to finish fast. But I am going to bed now, so when I look next, it might be finished. It is not a build from an empty tree, though, just from make all doc-clean doc. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed make doc for Patchy
David Kastrup d...@gnu.org writes: Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Wednesday, March 14, 2012 7:16 PM Subject: Re: Failed make doc for Patchy James pkx1...@gmail.com writes: I am not at home but Patchy complained just now. Shall I run patchy and check the logfiles? I am currently running make doc, but it does not look like it is going to finish fast. But I am going to bed now, so when I look next, it might be finished. It is not a build from an empty tree, though, just from make all doc-clean doc. It is commit bb726728d07f5d155e061b360101028c4a4618e8 Author: Carl c_soren...@byu.edu Date: Sat Mar 10 11:47:54 2012 -0700 Fix make error in regression tests coming from midi2ly I have been unable to complete make test-baseline because of errors in the files coming from midi2ly.py. I tracked the error to make/midi-rules.make. The change in this patch allows me to successfully complete make test-baseli my computer, running OSX 10.5.8, with GNU Make 3.81. This change results in \\ in the headers getting reduced to just \ and that trips up TeX. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed make doc for Patchy
Hello,
On 14 March 2012 20:04, David Kastrup d...@gnu.org wrote:
Phil Holmes m...@philholmes.net writes:
- Original Message -
From: David Kastrup d...@gnu.org
To: lilypond-devel@gnu.org
Sent: Wednesday, March 14, 2012 7:16 PM
Subject: Re: Failed make doc for Patchy
James pkx1...@gmail.com writes:
I am not at home but Patchy complained just now.
Shall I run patchy and check the logfiles?
I've just done it and I get this file that causes the complaints
--snip--
%
% Start cut--pastable-section
%
\paper {
indent = 0\mm
line-width = 160\mm
% offset the left padding, also add 1mm as lilypond creates cropped
% images with a little space on the right
line-width = #(- line-width (* mm 3.00) (* mm 1))
}
\layout {
}
%
% ly snippet:
%
\sourcefilename out-www/voice-2-midi.ly
\sourcefileline 0
% Lily was here -- automatically converted by
/home/james/lilypond-git/scripts/midi2ly.py from out-www/voice-2.midi
\version 2.14.0
\layout {
\context {
\Voice
\remove Note_heads_engraver
\consists Completion_heads_engraver
\remove Rest_engraver
\consists Completion_rest_engraver
}
}
% included from ./out-www/voice-2.header
\header {
texidoc=midi2ly maps two voices nicely on one staff as oiceOne, oiceTwo
options=
}
% end
trackAchannelA = {
% [SEQUENCE_TRACK_NAME] control track
% [TEXT_EVENT] creator:
% [TEXT_EVENT] GNU LilyPond 2.15.34
\time 4/4
\tempo 4 = 60
}
trackA =
\context Voice = voiceA \trackAchannelA
trackBchannelA = {
\set Staff.instrumentName = trackB:voiceA
}
trackBchannelB = {
\set Staff.instrumentName = trackB:voiceB
}
trackBchannelC = \relative c {
\voiceOne
e''4 e e e
| % 2
}
trackBchannelD = \relative c {
\voiceTwo
f' f f f
| % 2
}
trackB =
\context Voice = voiceA \trackBchannelA
\context Voice = voiceB \trackBchannelB
\context Voice = voiceC \trackBchannelC
\context Voice = voiceD \trackBchannelD
\score {
\context Staff=trackB \trackA
\context Staff=trackB \trackB
\layout {}
\midi {}
}
%
% end ly snippet
%
--snip--
--
--
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: font regression build regression
Hello, On 14 March 2012 20:00, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: lilypond-devel@gnu.org Sent: Wednesday, March 14, 2012 7:59 PM Subject: font regression build regression Has anybody else seen a huge slow-down in building fonts? They used to whiz by on my screen in a minute or so, but now it takes about 10 minutes, and more to the point, it involves a massive amount of disk activity. My core2quad desktop couldn't play an mp3 file while building fonts with -j3 ! Might it be building the same font multiple times (with different threads creating and deleting the same temporary files?), or are we generating fonts at twice the resolution of the previous one, or...? It's been a few weeks since I tried building stuff from scratch, which leaves a large window of work on the build system and fonts. Is this with a straight make ? I ran it yesterday and didn't see a slowdown, and I always check the time it takes. I did a make on my 1cpu LilyDev VM (when I am work) on 1GB of memory today and didn't see any significant slow down on a 'make'. It takes about 10 minutes. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: font regression build regression
On Wed, Mar 14, 2012 at 08:00:44PM -, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: lilypond-devel@gnu.org Sent: Wednesday, March 14, 2012 7:59 PM Subject: font regression build regression Has anybody else seen a huge slow-down in building fonts? They used to whiz by on my screen in a minute or so, but now it takes about 10 minutes, and more to the point, it involves a massive amount of disk activity. My core2quad desktop couldn't play an mp3 file while building fonts with -j3 ! Is this with a straight make ? I ran it yesterday and didn't see a slowdown, and I always check the time it takes. Yes, a straight make, after completely removing the build dir and running autogen.sh --noconfigure. Maybe my hard disk is just about to die. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Turns off TupletBracket collision avoidance if Script avoids slur (issue 5821051)
Reviewers: , Message: Meh...not my best work, but it is a first step towards fixing this problem. A full solution would do tuplet avoidance for scripts in the same way they're done for slurs. Takers? Description: Turns off TupletBracket collision avoidance if Script avoids slur Please review this at http://codereview.appspot.com/5821051/ Affected files: M lily/tuplet-bracket.cc Index: lily/tuplet-bracket.cc diff --git a/lily/tuplet-bracket.cc b/lily/tuplet-bracket.cc index 40e0c728c5ef2c353de391bd5da025386bce7007..8e4a3c017ce4ee6f0a3b2089810396063f8aa55b 100644 --- a/lily/tuplet-bracket.cc +++ b/lily/tuplet-bracket.cc @@ -669,6 +669,13 @@ Tuplet_bracket::calc_position_and_height (Grob *me_grob, Real *offset, Real *dy) if (scm_is_number (scripts[i]-get_property (outside-staff-priority))) continue; + // assume that if a script is avoiding slurs, it should not get placed + // under a tuplet bracket + SCM avoid = scripts[i]-get_property (avoid-slur); + if (avoid == ly_symbol2scm (outside) + || avoid == ly_symbol2scm (around)) +continue; + Interval script_x (scripts[i]-extent (commonx, X_AXIS)); Interval script_y (scripts[i]-extent (commony, Y_AXIS)); ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed make doc for Patchy
James pkx1...@gmail.com writes: Hello, On 14 March 2012 20:04, David Kastrup d...@gnu.org wrote: Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Wednesday, March 14, 2012 7:16 PM Subject: Re: Failed make doc for Patchy James pkx1...@gmail.com writes: I am not at home but Patchy complained just now. Shall I run patchy and check the logfiles? I've just done it and I get this file that causes the complaints Yup, echo turns \v into vertical tab. Really daft. bb726728d07f5d155e061b360101028c4a4618e8 will need to get done differently. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed make doc for Patchy
David Kastrup d...@gnu.org writes: James pkx1...@gmail.com writes: Hello, On 14 March 2012 20:04, David Kastrup d...@gnu.org wrote: Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Wednesday, March 14, 2012 7:16 PM Subject: Re: Failed make doc for Patchy James pkx1...@gmail.com writes: I am not at home but Patchy complained just now. Shall I run patchy and check the logfiles? I've just done it and I get this file that causes the complaints Yup, echo turns \v into vertical tab. Really daft. bb726728d07f5d155e061b360101028c4a4618e8 will need to get done differently. I backed it out of staging. Try again. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed make doc for Patchy
On 3/14/12 3:12 PM, David Kastrup d...@gnu.org wrote: I backed it out of staging. Try again. Thanks, David. I guess if I figure out another fix, I'll have to try it on lilydev to make sure it works there as well as here. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] Fix mordents and pralltriller in articulate.ly
On Wed, Mar 14, 2012 at 4:39 PM, Graham Percival gra...@percival-music.ca wrote: On Wed, Mar 14, 2012 at 01:39:11PM +, James wrote: I think this needs to be reviewed just like any other patch should be, why *would* we just push this? Well, I think this one is simple enough to push directly. Shall i do this? And shall i not ask next time? ;) http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=d11dbf277719c0179c5520154c925839d969a535 I might have missed this but did this have a tracker/patchy test? I think that was also simple enough not to need an individual patchy test. As long as it was pushed to staging and not master, stuff that simple is fine. That was also my reasoning. It's unbelievable how much time is spend on patch maintenance... A simple change can take 5 days (in my case it means 5 days of constant awareness about the patch)... cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed make doc for Patchy
Carl Sorensen c_soren...@byu.edu writes: On 3/14/12 3:12 PM, David Kastrup d...@gnu.org wrote: I backed it out of staging. Try again. Thanks, David. I guess if I figure out another fix, I'll have to try it on lilydev to make sure it works there as well as here. Afraid so. bash has no problem with echo '\v', but dash, the default /bin/sh in Ubuntu, cranks out a vertical tab. And the MacOSX /bin/sh is the first shell I heard of that does not grok echo -n. Autoconf offers the following in portable shell programming: `echo' The simple `echo' is probably the most surprising source of portability troubles. It is not possible to use `echo' portably unless both options and escape sequences are omitted. Don't expect any option. Do not use backslashes in the arguments, as there is no consensus on their handling. For `echo '\n' | wc -l', the `sh' of Solaris outputs 2, but Bash and Zsh (in `sh' emulation mode) output 1. The problem is truly `echo': all the shells understand `'\n'' as the string composed of a backslash and an `n'. Within a command substitution, `echo 'string\c'' will mess up the internal state of ksh88 on AIX 6.1 so that it will print the first character `s' only, followed by a newline, and then entirely drop the output of the next echo in a command substitution. Because of these problems, do not pass a string containing arbitrary characters to `echo'. For example, `echo $foo' is safe only if you know that FOO's value cannot contain backslashes and cannot start with `-'. If this may not be true, `printf' is in general safer and easier to use than `echo' and `echo -n'. Thus, scripts where portability is not a major concern should use `printf '%s\n'' whenever `echo' could fail, and similarly use `printf %s' instead of `echo -n'. For portable shell scripts, instead, it is suggested to use a here-document like this: cat EOF $foo EOF Alternatively, M4sh provides `AS_ECHO' and `AS_ECHO_N' macros which choose between various portable implementations: `echo' or `print' where they work, `printf' if it is available, or else other creative tricks in order to work around the above problems. The problem with a here-document is that it requires passing newlines into the shell script, and that is something that Make does not care for. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] Fix mordents and pralltriller in articulate.ly
Janek Warchoł janek.lilyp...@gmail.com writes: On Wed, Mar 14, 2012 at 4:39 PM, Graham Percival gra...@percival-music.ca wrote: On Wed, Mar 14, 2012 at 01:39:11PM +, James wrote: I think this needs to be reviewed just like any other patch should be, why *would* we just push this? Well, I think this one is simple enough to push directly. Shall i do this? And shall i not ask next time? ;) http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=d11dbf277719c0179c5520154c925839d969a535 I might have missed this but did this have a tracker/patchy test? I think that was also simple enough not to need an individual patchy test. As long as it was pushed to staging and not master, stuff that simple is fine. That was also my reasoning. It's unbelievable how much time is spend on patch maintenance... A simple change can take 5 days (in my case it means 5 days of constant awareness about the patch)... The alternatives have shown a tendency to lock up development for everyone. Not everything goes through the full cycle, but it's not rare that even trivial things get valid comments and corrections. No constant awareness is required. Patches move from Patch-new to Patch-review to Patch-countdown to Patch-push without the patch originator being required to bother about it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: font regression build regression
On Wed, Mar 14, 2012 at 9:28 PM, Graham Percival gra...@percival-music.ca wrote: On Wed, Mar 14, 2012 at 08:00:44PM -, Phil Holmes wrote: Is this with a straight make ? I ran it yesterday and didn't see a slowdown, and I always check the time it takes. Yes, a straight make, after completely removing the build dir and running autogen.sh --noconfigure. I've checked now and make from scratch took 6 minutes, as usual on my machine. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed make doc for Patchy
On Wed, Mar 14, 2012 at 10:27:52PM +0100, David Kastrup wrote: And the MacOSX /bin/sh is the first shell I heard of that does not grok echo -n. ... If this may not be true, `printf' is in general safer and easier to use than `echo' and `echo -n'. This matches the open group specifications. http://pubs.opengroup.org/onlinepubs/009695399/utilities/echo.html ... APPLICATION USAGE It is not possible to use echo portably across all POSIX systems unless both -n (as the first argument) and escape sequences are omitted. The printf utility can be used portably to emulate any of the traditional behaviors of the echo utility as follows (assuming that IFS has its standard value or is unset): The historic System V echo and the requirements on XSI implementations in this volume of IEEE Std 1003.1-2001 are equivalent to: printf %b\n $* The BSD echo is equivalent to: if [ X$1 = X-n ] then shift printf %s $* else printf %s\n $* fi New applications are encouraged to use printf instead of echo. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] Fix mordents and pralltriller in articulate.ly
On Wed, Mar 14, 2012 at 10:25:40PM +0100, Janek Warchoł wrote: On Wed, Mar 14, 2012 at 4:39 PM, Graham Percival gra...@percival-music.ca wrote: Well, I think this one is simple enough to push directly. Shall i do this? And shall i not ask next time? ;) If you are certain that it will cause no problems, and willing to take responsibility if it does cause problems after all. I think that was also simple enough not to need an individual patchy test. As long as it was pushed to staging and not master, stuff that simple is fine. That was also my reasoning. It's unbelievable how much time is spend on patch maintenance... A simple change can take 5 days (in my case it means 5 days of constant awareness about the patch)... Oh? And yet, a few hours ago, we saw that a questionable patch in staging. We had to look at it manually, back it out, do a forced-updated of that branch which changes all committishes... it's a pain. If you're willing to work on improving things, write a python script that takes care of putting stuff on a countdown. That's a task that's trivially done by a script, and it'll exercise your python and json knowledge. See the Patchy code for hints. If you're not interested in doing that type of work, fine; we can live with the status quo. (no, the automatic countdown won't address patch-handling concerns arising from this specific instance, but an automatic countdown is the easiest thing we can automate. If nobody is interested in doing that, there's no point discussing more complicated things) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] Fix mordents and pralltriller in articulate.ly
On Wed, Mar 14, 2012 at 10:33 PM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: On Wed, Mar 14, 2012 at 4:39 PM, Graham Percival gra...@percival-music.ca wrote: On Wed, Mar 14, 2012 at 01:39:11PM +, James wrote: I think this needs to be reviewed just like any other patch should be, why *would* we just push this? Well, I think this one is simple enough to push directly. Shall i do this? And shall i not ask next time? ;) http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=d11dbf277719c0179c5520154c925839d969a535 I might have missed this but did this have a tracker/patchy test? I think that was also simple enough not to need an individual patchy test. As long as it was pushed to staging and not master, stuff that simple is fine. That was also my reasoning. It's unbelievable how much time is spend on patch maintenance... A simple change can take 5 days (in my case it means 5 days of constant awareness about the patch)... The alternatives have shown a tendency to lock up development for everyone. Not everything goes through the full cycle, but it's not rare that even trivial things get valid comments and corrections. true and i don't mean to complain. I just wish i had more time. No constant awareness is required. Patches move from Patch-new to Patch-review to Patch-countdown to Patch-push without the patch originator being required to bother about it. Doesn't work well in my case. Until the issue is closed, it's hard for me to forget about it. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] Fix mordents and pralltriller in articulate.ly
On Wed, Mar 14, 2012 at 10:41 PM, Graham Percival gra...@percival-music.ca wrote: On Wed, Mar 14, 2012 at 10:25:40PM +0100, Janek Warchoł wrote: On Wed, Mar 14, 2012 at 4:39 PM, Graham Percival gra...@percival-music.ca wrote: Well, I think this one is simple enough to push directly. Shall i do this? And shall i not ask next time? ;) If you are certain that it will cause no problems, and willing to take responsibility if it does cause problems after all. ok, i won't push it then. That was also my reasoning. It's unbelievable how much time is spend on patch maintenance... A simple change can take 5 days (in my case it means 5 days of constant awareness about the patch)... Oh? And yet, a few hours ago, we saw that a questionable patch in staging. We had to look at it manually, back it out, do a forced-updated of that branch which changes all committishes... it's a pain. i'm sorry, i didn't mean to complain. It's a problem i have with myself, not with our workflow. If you're willing to work on improving things, write a python script that takes care of putting stuff on a countdown. That's a task that's trivially done by a script, and it'll exercise your python and json knowledge. See the Patchy code for hints. If you're not interested in doing that type of work, fine; we can live with the status quo. (no, the automatic countdown won't address patch-handling concerns arising from this specific instance, but an automatic countdown is the easiest thing we can automate. If nobody is interested in doing that, there's no point discussing more complicated things) I'm interested in doing this, when i finish these: - announce Regtest Rater - write application to GSoC if Lily is accepted - write text for new LilyPond Report - organize a Kickstarter project. I find the above more urgent/important. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] Fix mordents and pralltriller in articulate.ly
- Original Message - From: Graham Percival gra...@percival-music.ca To: Janek Warchoł janek.lilyp...@gmail.com Cc: lilypond-devel@gnu.org Sent: Wednesday, March 14, 2012 9:41 PM Subject: Re: [patch] Fix mordents and pralltriller in articulate.ly On Wed, Mar 14, 2012 at 10:25:40PM +0100, Janek Warchoł wrote: On Wed, Mar 14, 2012 at 4:39 PM, Graham Percival gra...@percival-music.ca wrote: Well, I think this one is simple enough to push directly. Shall i do this? And shall i not ask next time? ;) If you are certain that it will cause no problems, and willing to take responsibility if it does cause problems after all. I guess my view would be that you should never push to staging unless you've had a successful make, make doc. I think you could probably add make test to that list. If you think it's uncontroversial and passes those tests, then push to staging. In principle, this makes patchy redundant. In practice, I was still bitten when I had a snippet added on my system which wasn't in git - so patchy still prevents problems to master. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed make doc for Patchy
Graham Percival gra...@percival-music.ca writes:
On Wed, Mar 14, 2012 at 10:27:52PM +0100, David Kastrup wrote:
And the MacOSX /bin/sh is the first shell I heard of that does not grok
echo -n.
...
If this may not be true, `printf' is in general safer and easier
to use than `echo' and `echo -n'.
This matches the open group specifications.
http://pubs.opengroup.org/onlinepubs/009695399/utilities/echo.html
...
APPLICATION USAGE
It is not possible to use echo portably across all POSIX
systems unless both -n (as the first argument) and escape
sequences are omitted.
Actually:
git grep echo -n
make/midi-rules.make: (echo '\header {'; for f in $(HEADER_FIELDS); do echo -n
mf/GNUmakefile: echo -n 'emmentaler-brace' $@
scripts/build/install-info-html.sh:echo -n $name: Writing index: $index_file...
smart-autogen.sh:echo -n $AUTOGEN_INPUT_CHECKSUM $CHECKSUM_FILE
smart-configure.sh:echo -n $CONFIGURE_CHECKSUM $CONFIGURE_CHECKSUM_FILE
stepmake/bin/stepmakeise.sh:echo -n Checking version...
stepmake/bin/stepmakeise.sh:echo -n Checking latest...
stepmake/bin/stepmakeise.sh:echo -n Updating StepMake...
stepmake/bin/stepmakeise.sh:echo -n Stepmakeising...
Wonderful.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Various updates to reduce make doc output (issue 5727055)
Carl Sorensen wrote Wednesday, March 14, 2012 6:01 PM On 3/14/12 11:48 AM, Phil Holmes m...@philholmes.net wrote: I've looked at midi2ly and it uses explicit instantiation of voices, which is what we normally advise. My understanding is that there are only 4 explicit voices - voiceFive does not exist, AFAIK. The warning message comes from midi2ly stating that it has no more explicit voice names left, and therefore layout is likely to be poor. We don't need to see this during make doc. If I read the snippet correctly (Additional voices to avoid collisions, in NR 1.5.2), there is no limit to the number of voices in LilyPond. But only four voices are defined. In the snippet, voiceFive is defined, before it is used. So it would be nice to have a feature added to midi2ly that would automatically create voiceFive, voiceSix, etc. if needed. Exactly! Having discovered the problem, the correct procedure is to raise an issue for it, not try to hide it. It would be easy to add a couple of extra voices to ly/property-init.ly, if that would make it easier to fix midi2ly. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix mordents and pralltriller in articulate.ly (issue 5829043)
looks basically good, but two minor points. Make that three minor points: please CC to -devel, not -devl. http://codereview.appspot.com/5829043/diff/1/ly/articulate.ly File ly/articulate.ly (right): http://codereview.appspot.com/5829043/diff/1/ly/articulate.ly#newcode482 ly/articulate.ly:482: (let ((pset (make-music 'PropertySet The indentation looks a bit off, but we don't have a tool for scheme indentation, nor do we even have any consistency in terms of spaces vs. tabs in .scm files, so good enough for me. http://codereview.appspot.com/5829043/diff/1/ly/articulate.ly#newcode625 ly/articulate.ly:625: (else music)) extra space? http://codereview.appspot.com/5829043/diff/1/ly/articulate.ly#newcode630 ly/articulate.ly:630: % At last ... here's the music function that aplies all the above to a this adds a typo? http://codereview.appspot.com/5829043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix mordents and pralltriller in articulate.ly (issue 5829043)
Reviewers: Graham Percival, Message: On 2012/03/15 00:49:01, Graham Percival wrote: looks basically good, but two minor points. One big issue -- the patch is reversed. My bad in attempting to use git-cl. I'm currently trying to work out how to delete this issue and create a new one with the patch the right way around. Make that three minor points: please CC to -devel, not -devl. http://codereview.appspot.com/5829043/diff/1/ly/articulate.ly File ly/articulate.ly (right): http://codereview.appspot.com/5829043/diff/1/ly/articulate.ly#newcode482 ly/articulate.ly:482: (let ((pset (make-music 'PropertySet The indentation looks a bit off, but we don't have a tool for scheme indentation, nor do we even have any consistency in terms of spaces vs. tabs in .scm files, so good enough for me. http://codereview.appspot.com/5829043/diff/1/ly/articulate.ly#newcode625 ly/articulate.ly:625: (else music)) extra space? http://codereview.appspot.com/5829043/diff/1/ly/articulate.ly#newcode630 ly/articulate.ly:630: % At last ... here's the music function that aplies all the above to a this adds a typo? Description: Fix mordents and pralltriller in articulate.ly Mordents should be on-beat, not grace notes. And pralltrillers (half-shakes) are always either 4 alternating notes, or an inverted mordent. There is of course a general problem here in that the way ornaments are realised has changed through the centuries. Even Bach and Clementi disagree! I'm following CPE Bach's `True art of Keyboard Playing' in the interpretation here. To do the job properly we'd have two articulations: \prall and \inverted_mordent and treat them separately for MIDI, but typeset the same glyph. Reported-by: Christopher Maden cr...@maden.org Signed-off-by: Peter Chubb peter.ch...@nicta.com.au Please review this at http://codereview.appspot.com/5829043/ Affected files: M ly/articulate.ly Index: ly/articulate.ly diff --git a/ly/articulate.ly b/ly/articulate.ly index a345468ef71395bb745f1e867fc9d525a4d56526..d2d3b182ffd3dd835e607c53bf39f0f4cb3832f5 100644 --- a/ly/articulate.ly +++ b/ly/articulate.ly @@ -341,18 +341,8 @@ ; (ac:accel trillMusic factor)) ))) -% -% Generate a tempoChangeEvent and its associated property setting. -% -#(define (ac:tempoChange tempo) - (make-sequential-music - (list (make-music 'TempoChangeEvent - 'metronome-count - tempo - 'tempo-unit - (ly:make-duration 0 0 1 1)) -(context-spec-music -(make-property-set 'tempoWholesPerMinute tempo) 'Score + + % If there's an articulation, use it. % If in a slur, use (1 . 1) instead. @@ -424,14 +414,6 @@ (string= t rall.)) (loop factor (cons e newelements) tail (cons 'rall actions))) ((or -(string= t accelerando) -(string= t accel) -(string= t accel.)) - (loop factor (cons e newelements) tail (cons 'accel actions))) - ((or -(string= t poco accel.)) - (loop factor (cons e newelements) tail (cons 'pocoAccel actions))) - ((or (string= t poco rall.) (string= t poco rit.)) (loop factor (cons e newelements) tail (cons 'pocoRall actions))) @@ -495,37 +477,25 @@ (make-music 'RestEvent 'duration (ly:make-duration len dots newnum newdenom)) music))) - ((accel) - (set! ac:lastTempo ac:currentTempo) - (set! ac:currentTempo (ly:moment-div ac:currentTempo ac:rallFactor)) - (let ((pset (ac:tempoChange ac:currentTempo))) -(if (null? (cdr actions)) - (make-sequential-music (list pset music)) - (make-sequential-music - (list pset (loop (cdr actions))) - - ((pocoAccel) - (set! ac:lastTempo ac:currentTempo) - (set! ac:currentTempo (ly:moment-div ac:currentTempo ac:pocoRallFactor)) - (let ((pset (ac:tempoChange ac:currentTempo))) -(if (null? (cdr actions)) - (make-sequential-music (list pset music)) - (make-sequential-music - (list pset (loop (cdr actions))) - ((rall) - (set! ac:lastTempo ac:currentTempo) (set! ac:currentTempo (ly:moment-mul ac:currentTempo ac:rallFactor)) - (let ((pset (ac:tempoChange ac:currentTempo))) + (let ((pset (make-music 'PropertySet + 'value + ac:currentTempo + 'symbol + 'tempoWholesPerMinute))) (if (null? (cdr actions)) (make-sequential-music (list pset music)) (make-sequential-music (list pset (loop (cdr actions))) ((pocoRall) - (set! ac:lastTempo ac:currentTempo) (set! ac:currentTempo (ly:moment-mul ac:currentTempo ac:pocoRallFactor)) - (let ((pset (ac:tempoChange ac:currentTempo))) + (let ((pset (make-music 'PropertySet + 'value + ac:currentTempo + 'symbol +
Re: Fix mordents and pralltriller in articulate.ly (issue 5784084)
ok. In the future, when updating a patch, please point git-cl at your existing issue (which was orginally 2404, but I'm going to close 2404 and 2405 and leave 2406). At a rough analogy, the code.google issue number is a pointer, while the rietveld is a piece of memory. We don't care how often you allocate and delete memory, as long as you keep a single pointer. Also, fix your -devl CC. Look at your .git/config http://codereview.appspot.com/5784084/diff/1003/ly/articulate.ly File ly/articulate.ly (right): http://codereview.appspot.com/5784084/diff/1003/ly/articulate.ly#newcode572 ly/articulate.ly:572: ) technically I think this ) should go on the line above http://codereview.appspot.com/5784084/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix mordents and pralltriller in articulate.ly (issue 5784084)
On Thu, Mar 15, 2012 at 02:49:29PM +1100, Peter Chubb wrote: graham == graham gra...@percival-music.ca writes: graham ok. In the future, when updating a patch, please point git-cl graham at your existing issue (which was orginally 2404, but I'm graham going to close 2404 and 2405 and leave 2406). Can I do that in .git/config? Unfortunately not. It currently points at a Rietveld issue 5784084 --- I wasn't aware that there was a separate Lilypond issue number name space. Is git-cl meant to print out the new Lilypond issue number? git-cl will say I can't find an issue number; at that point, manually type in 2406. Hopefully somebody will add code.google-issue-number-tracking to git-cl at some point, but that's not likely to happen soon. I think the (begin is unnecessary too. I was a real novice scheme programmer when I wrote all this --- still am. The body of a let clause is already a list of fucntion calls. Well, each patch will need to go through the review. You could let the current ones go through, then do more edits; or you could cancel the current one, make more edits, then send a single patch through. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
