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 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
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 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 Signed-off-by: Peter Chubb 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 + 'tempoWholesPerMinute
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: 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" 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
Re: Failed make doc for Patchy
Graham Percival 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: [patch] Fix mordents and pralltriller in articulate.ly
- Original Message - From: "Graham Percival" To: "Janek Warchoł" Cc: 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 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: [patch] Fix mordents and pralltriller in articulate.ly
On Wed, Mar 14, 2012 at 10:41 PM, Graham Percival 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 >> 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
On Wed, Mar 14, 2012 at 10:33 PM, David Kastrup wrote: > Janek Warchoł writes: > >> On Wed, Mar 14, 2012 at 4:39 PM, Graham Percival >> 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:25:40PM +0100, Janek Warchoł wrote: > On Wed, Mar 14, 2012 at 4:39 PM, Graham Percival > 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: 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: font regression build regression
On Wed, Mar 14, 2012 at 9:28 PM, Graham Percival 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: [patch] Fix mordents and pralltriller in articulate.ly
Janek Warchoł writes: > On Wed, Mar 14, 2012 at 4:39 PM, Graham Percival > 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: Failed make doc for Patchy
Carl Sorensen writes: > On 3/14/12 3:12 PM, "David Kastrup" 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
Re: [patch] Fix mordents and pralltriller in articulate.ly
On Wed, Mar 14, 2012 at 4:39 PM, Graham Percival 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
On 3/14/12 3:12 PM, "David Kastrup" 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: Failed make doc for Patchy
David Kastrup writes: > James writes: > >> Hello, >> >> On 14 March 2012 20:04, David Kastrup wrote: >>> "Phil Holmes" writes: >>> - Original Message - From: "David Kastrup" To: Sent: Wednesday, March 14, 2012 7:16 PM Subject: Re: Failed make doc for Patchy James 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
James writes: > Hello, > > On 14 March 2012 20:04, David Kastrup wrote: >> "Phil Holmes" writes: >> >>> - Original Message - >>> From: "David Kastrup" >>> To: >>> Sent: Wednesday, March 14, 2012 7:16 PM >>> Subject: Re: Failed make doc for Patchy >>> >>> >>> James 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
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: font regression build regression
On Wed, Mar 14, 2012 at 08:00:44PM -, Phil Holmes wrote: > - Original Message - From: "Graham Percival" > > To: > 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
Re: font regression build regression
Hello, On 14 March 2012 20:00, Phil Holmes wrote: > - Original Message - From: "Graham Percival" > > To: > 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: Failed make doc for Patchy
Hello, On 14 March 2012 20:04, David Kastrup wrote: > "Phil Holmes" writes: > >> - Original Message - >> From: "David Kastrup" >> To: >> Sent: Wednesday, March 14, 2012 7:16 PM >> Subject: Re: Failed make doc for Patchy >> >> >> James 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: Failed make doc for Patchy
David Kastrup writes: > "Phil Holmes" writes: > >> - Original Message - >> From: "David Kastrup" >> To: >> Sent: Wednesday, March 14, 2012 7:16 PM >> Subject: Re: Failed make doc for Patchy >> >> >> James 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 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
"Phil Holmes" writes: > - Original Message - > From: "David Kastrup" > To: > Sent: Wednesday, March 14, 2012 7:16 PM > Subject: Re: Failed make doc for Patchy > > > James 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
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: font regression build regression
- Original Message - From: "Graham Percival" To: 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
Re: Failed make doc for Patchy
- Original Message - From: "David Kastrup" To: Sent: Wednesday, March 14, 2012 7:16 PM Subject: Re: Failed make doc for Patchy James 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
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
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
Re: Failed make doc for Patchy
Graham Percival 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 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
James writes: > I am not at home but Patchy complained just now. > > > -- Forwarded message -- > From: > 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 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
Failed make doc for Patchy
I am not at home but Patchy complained just now. -- Forwarded message -- From: 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: Various updates to reduce make doc output (issue 5727055)
On 3/14/12 11:48 AM, "Phil Holmes" wrote: >- Original Message - >From: "Trevor Daniels" >To: "Phil Holmes" >Cc: "Lily-Devel List" >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
Re: Various updates to reduce make doc output (issue 5727055)
- Original Message - From: "Trevor Daniels" To: "Phil Holmes" Cc: "Lily-Devel List" 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" To: "Julien Rioux" ; "Phil Holmes" Cc: ; 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 wrote: - Original Message - From: "Julien Rioux" To: "Phil Holmes" 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)
Phil Holmes wrote Wednesday, March 14, 2012 12:00 PM From: "Trevor Daniels" To: "Julien Rioux" ; "Phil Holmes" Cc: ; 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 wrote: - Original Message - From: "Julien Rioux" To: "Phil Holmes" 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: [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: [patch] Fix mordents and pralltriller in articulate.ly
Hello, 2012/3/14 Janek Warchoł : > 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
[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 Signed-off-by: Peter Chubb 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: 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 wrote: - Original Message - From: "Julien Rioux" To: "Phil Holmes" 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
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 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 > Signed-off-by: Peter Chubb > > 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
page-count and annotate-spacing in documentation
On Tue, Mar 13, 2012 at 11:59 PM, Jean-Alexis Montignies 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: Various updates to reduce make doc output (issue 5727055)
On Wed, Mar 14, 2012 at 9:56 AM, Phil Holmes wrote: > - Original Message - From: "Julien Rioux" > To: "Phil Holmes" > >> > >> > 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
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: 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: 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: Various updates to reduce make doc output (issue 5727055)
- Original Message - From: "Julien Rioux" To: "Phil Holmes" > > 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