Menu
▾
▴
#2379 resetting autoBeaming after a cadenza
Originally created by: *anonymous
Originally created by: Elu...@gmail.com
Originally owned by: dak@gnu.org
usually, auto beaming after a cadenza keeps turned off if it continues with a grace
\version "2.15.31"
\relative c' {
e8 e e e e e e e
\cadenzaOn
e e e e e e e e
\cadenzaOff
\bar "|"
\grace f8
e e e e e e e e
}
a workaround has been elaborated by David Bobroff using
\set Timing.measurePosition = #(ly:make-moment 0 4)
at the right place - which is after \cadenzaOff and between the \bar and the \grace:
\relative c' {
e8 e e e e e e e
\cadenzaOn
e e e e e e e e
\cadenzaOff
\bar "|"
\grace f8
\set Timing.measurePosition = #(ly:make-moment 0 4)
e e e e e e e e
}
see http://old.nabble.com/%5Cgrace-after-%5CcadenzaOff-suppresses-auto-beams-ts33437479.html for more details
don't know if this can turned on automagically or if it should be added in the docs (as known issues and workarounds)
Originally posted by: colingh...@gmail.com
David Bobroff restated the problem in a post here:
http://lists.gnu.org/archive/html/bug-lilypond/2012-03/msg00238.html
Text of original post follows:
I'm re-framing my query regarding accidental behavior following \cadenzaOff. After some discussion about this on bug- it is quite clear that '\cadenzaOff' *only* affects counting/timing and '\bar' *only* paints a graphic of a bar line. Currently, if an accidental appears in the cadenza it will be visibly canceled if the key signature value of the note is used in the next "measure" even if '\cadenzaOff \bar "|."' is present. Musically this should not happen. Since a bar line has gone by the key signature is back in force.
This post in on -user to see if anyone has a solution; how do I suppress the accidental cancellation in the following example?
I've posted this to bug- to suggest that LilyPond should probably understand this.
Example:
%%%
\version "2.14.2"
\relative c'
{
\key c \major
\time 2/4
c2 ~
\cadenzaOn
c4 \teeny d8-[ es f g-] \normalsize a4-\fermata
\cadenzaOff
\bar "|"
e2 % how to suppress accidental cancellation here?
}
%%%
-David
Originally posted by: colingh...@gmail.com
David Bobroff sent in another bug report related to cadenzas.
http://lists.gnu.org/archive/html/bug-lilypond/2012-03/msg00203.html
http://article.gmane.org/gmane.comp.gnu.lilypond.bugs/34321
Originally posted by: colingh...@gmail.com
Nathan Williams reported surprising behaviour:
http://lists.gnu.org/archive/html/bug-lilypond/2012-05/msg00060.html
Original post follows:
When using a cadenza across several measures (for engraving unmetered Russian
liturgical music), accidentals are displayed only the first time they occur.
I.e.:
\cadenzaOn
d4 e f2( d8[ e] f4) f f4 f( e2 f4) d1
\bar "|"
e4 e e f( e) d cs d1
\bar "|"
f2 ( d8[ e] f4) f f4 f( e2) f4 d1
\bar "|"
e4 e e f( e d) cs d1
\bar "|"
f2 ( d8[ e] f4) f f( e2 f4 d2 f4 e d cs d) e d1
\bar "|"
e4 e e e f( e) d cs8([ d] e4 d cs) d1
\bar "||"
\cadenzaOff
C sharp, which occurs in lines 2, 4, 5, and 6, is only displayed the first time
it occurs, in line 2.
Since using \cadenzaOn and \cadenzaOff is a recommended solution for engraving
unmetered music (see
http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Working-with-ancient-music_002d_002dscenarios-and-solutions),
it would be great if the issue were corrected, or else a workaround provided and
the issue inserted on the above page in the "known issues and warnings" section.
Thank you!
Originally posted by: dak@gnu.org
These are three different issue reports. The title and issue description is about autoBeaming after cadenze when a grace note is first, then follows a comment "David Bobroff restated the problem" which is totally about something else, namely accidental behavior after cadenze. Then follows a comment "David Bobroff sent in another bug report" which is about the original problem.
Then follows another report about accidental behavior _inside_ of cadenze when explicit barlines are used.
Can we get this kind of stuff better sorted? It makes it rather hard to address individual problems when they are all clumped into a single report.
Originally posted by: dak@gnu.org
Since it does not look like anybody else wants to do this, I'm pulling this report apart into pieces myself. I've moved the accidental problems into issue 3640. Colin, could you delete the respective comments #1 and #3 in this report? I can't do that for you.
Originally posted by: dak@gnu.org
Ok, here is what happens in the original report (in a slightly modified manner it still happens after issue 3633 has been committed):
\cadenzaOff switches the timing back on before the grace note, and measurePosition is reset to (or after issue 3633, continues from) time 0+G0 while currentMoment is at 0-G1/8. When currentMoment advances to 0+G0, measurePosition advances to the rather strange position 0+G1/8 and steps through the measure with that offset of measurePosition, confusing the autobeamer (it is surprising that there does not seem all that much other confusion here).
Originally posted by: dak@gnu.org
Issue 2379: resetting autoBeaming after a cadenza
Letting measurePosition track the grace state of current_moment
unconditionally keeps it from moving into uncharted territory when
Timing.timing gets switched on or off during grace times.
http://codereview.appspot.com/20210043
Labels: Patch-new
Owner: dak@gnu.org
Status: Started
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted by: dak@gnu.org
Ok, I'm having a slight problem here. The situation that this patch is supposed to cure is acerbated by
Issue 3633: Freeze measurePosition while Timing.timing is off
since now any _difference_ between the grace timing of \cadenzaOn and \cadenzaOff will trigger the underlying problem for this patch. That's worse than the original problem that was merely triggered by a grace following \cadenzaOff. The ugly thing about this patch here is that it sacrifices measurePosition monotonicity when the main time is frozen while the grace time walks on asynchronously. On the other hand, measurePosition is not monotonic across bar boundaries anyway, so chances are that code is more or less able to cope.
The alternative solution of keeping measurePosition's grace timing tethered to zero leaves less information for beaming and other stuff to work with inside of graces.
So I'm pushing this one out in time for 2.17.95 to avoid a regression when a cadenza starts with a grace note. Again, I'm not enthused, but if it turns out to be problematic, it won't get cherry-picked into stable.
Test the heck out of this one if you have time/inclination.
Pushed to staging as
commit [r838825eb23e874d752c5b6080fd2c7a90ee4014b]
Author: David Kastrup <dak@gnu.org>
Date: Thu Oct 31 12:03:02 2013 +0100
Issue 2379: resetting autoBeaming after a cadenza
Letting measurePosition track the grace state of current_moment
unconditionally keeps it from moving into uncharted territory when
Timing.timing gets switched on or off during grace times.
Labels: -Patch-review Fixed_2_17_30
Status: Fixed
Originally posted by: Elu...@gmail.com
(No comment was entered for this change.)
Status: Verified