Originally created by: *anonymous
Originally created by: v.villenave
Originally owned by: dak@gnu.org
\version "2.11.47"
\relative c''
{
<< { \grace b8 c c c c } \\ { g g g g } >>
}
% This (incorrect) code produces some warnings, and both
% voices are printed with the stems down.
% Of course, the workaround is to add \grace s8 in the
% second voice.
Originally posted by: dak@gnu.org
This actually appears significantly different from issue 34 and is most likely the direct consequence of
commit [r4f795f5a103f6bf1c3a5590302ba54a361186524]
Author: Han-Wen Nienhuys <hanwen@xs4all.nl>
Date: Tue Apr 19 12:57:49 2005 +0000
(consider_change_grace_settings): new function.
(initialize): also consider_change_grace_settings() on
initialization. Fixes large grace notes at start of score.
Related
Issues: #34
Originally posted by: dak@gnu.org
Well, the commit mentioned in comment #26 is reasonably easy to revert but, uh, that does not change the outcome at all. I'm pretty sure I am looking at the right piece of code currently, however, namely the Grace_engraver and its manner of working with graceSettings. The timing of the overrides/reverts of the grace engraver are obviously interspersed with that of \voiceOne, with \voiceOne doing its reverts of previous voice settings (via pop-first, namely non-temporary overrides) after \grace has already established its settings, so when \grace at its end pops all settings it thinks it touched, it will not pop its own settings (which \voiceOne already did) but rather the ones by \voiceOne.
Originally posted by: dak@gnu.org
Ok, this is a nuisance. graceSettings is read and obeyed (setting other context/grob properties) in the Grace_engraver, but the usual property handling happens in iterators.
Now the main loop in global-context.cc is
send_stream_event (this, "Prepare", 0,
ly_symbol2scm ("moment"), w.smobbed_copy ());
if (iter->ok ())
iter->process (w);
send_stream_event (this, "OneTimeStep", 0, 0);
apply_finalizations ();
Prepare calls start_translation_timestep of all engravers, OneTimeStep calls process_music of all engravers followed by stop_translation_timestep. If Grace_engraver works at start_translation_timestep (like it does now), its actions precede that of any iterator setting properties. If it works at process_music time, its action may come too late for some grobs being created.
So there are two ways out:
a) let the Grace_iterator do the work instead.
b) let the Grace_engraver do its work in process_music but move it very early in the list of engravers so that its effects may occur in time for other engravers.
If the work is done in the engraver, there is no way whatsoever to distinguish
\oneVoice \grace { ... from \grace { \oneVoice ...
but the latter supposedly is \stemNeutral while the former is \stemUp. So the Grace_iterator at least has to grab graceSettings and stuff them into currentGraceSettings or something.
Which may not be visible to some Grace_engraver depending on what context in relation to the Grace_iterator it may be situated.
This is a nuisance.
Originally posted by: dak@gnu.org
Issue 630: non-synchronized grace note makes voiceOne go stems down
This is a complex issue not easy to tackle. Part 1 of this issue
stops the end of a grace section from popping property settings it has
not pushed itself, either by finding the original push below the
actual top of the property stack (when something got pushed during
grace time) or, when not finding it, doing nothing at all.
Issue 630/1: Implement Grob_property_info::matched_pop
This can be passed a token returned from Grob_property_info::push and
will then only revert the matching push or nothing at all. This is used
to limit the fallout from internal property reversions that might not
match the original override because of an intervening property push/pop.
Issue 630/2: Let grace_engraver only pop grob properties it pushed itself
Part 2 of this issue is concerned with the start of the grace section.
It tries figuring out whether any property setting commands adjacent
to \grace came immediately before or behind it and execute them in the
proper order. This can only work by letting the Grace_iterator
determine the timing. It communicates the timing via a GraceChange
event to the corresponding Grace_engraver. As there are several ways
in which the connection between iterator and engraver may be severed,
fallbacks are implemented. When they are being used, property setting
commands at the start of the \grace group may be executed before the
grace group sets its grace-specific properties.
Issue 630/3: Let Grace_iterator produce a GraceChange event
Issue 630/4: Let Grace_engraver react mostly to GraceChange events
When GraceChange events are not available, this reverts to grace processing
at initialization or at the engraver's process_music call.
http://codereview.appspot.com/150440043
Labels: Patch-new
Owner: dak@gnu.org
Status: Started
Originally posted by: dak@gnu.org
Reinstate acciaccatura in tab example removed during issue 2480
http://codereview.appspot.com/150440043
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests. There are two changed regtests. property-grace-polyphony.ly is now obviously correct. flags-straight-stockhausen-boulez.ly now has one acciaccatura drawn with the default grace Stem.length-fraction of 0.8 which is _correct_ since the intended stemLength of 0.95 is changed _outside_ of the acciaccatura itself. Will change the regtest accordingly.
Labels: -Patch-new Patch-review
Originally posted by: dak@gnu.org
Move override in flags-straight-stockhausen-boulez.ly
http://codereview.appspot.com/150440043
Labels: -Patch-review Patch-new
Originally posted by: dak@gnu.org
According to old archived regtests, property-grace-polyphony broke between version v2.4 and v2.6.
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests. Now the only changed regtest output is property-grace-polyphony and it is fixed as compared to previously.
Labels: -Patch-new Patch-review
Originally posted by: pkx1...@gmail.com
passes a make doc too (if that helps)
Originally posted by: dak@gnu.org
Issue 4144 has been merged into this issue.
Originally posted by: pkx1...@gmail.com
Patch on countdown for October 9th
Labels: -Patch-review Patch-countdown
Originally posted by: pkx1...@gmail.com
Patch counted down - please push
Labels: -Patch-countdown Patch-push
Originally posted by: dak@gnu.org
Pushed to staging as
commit [r649bfd6a9ad3d32eb17b460103464a8d997bf35b]
Author: David Kastrup <dak@gnu.org>
Date: Fri Oct 3 00:34:09 2014 +0200
Issue 630/6: Move override in flags-straight-stockhausen-boulez.ly
commit [raf941ebfc956af0a47341e29552d21af153ca961]
Author: David Kastrup <dak@gnu.org>
Date: Fri Oct 3 00:01:40 2014 +0200
Issue 630/5: Reinstate acciaccatura in tablature example
This was removed with commit [r2817ef1228cecd8b275fd666e0b5ba1bbd9406ce] in
version 2.15.38 since issue 630 was just too hard to work around.
commit [r99a85ca39f3a7a6f717ba06a48ef0ba70f842177]
Author: David Kastrup <dak@gnu.org>
Date: Wed Oct 1 19:39:08 2014 +0200
Issue 630/4: Let Grace_engraver react mostly to GraceChange events
When GraceChange events are not available, this reverts to grace processing
at initialization or at the engraver's process_music call.
commit [r6a023cc84879573668eaf9120bb13b93cfdf12cb]
Author: David Kastrup <dak@gnu.org>
Date: Thu Oct 2 16:13:51 2014 +0200
Issue 630/3: Let Grace_iterator produce a GraceChange event
commit [r7d737869f67f101dcc2c602a0fcccdfb7d0bd4a4]
Author: David Kastrup <dak@gnu.org>
Date: Wed Oct 1 16:55:07 2014 +0200
Issue 630/2: Let grace_engraver only pop grob properties it pushed itself
commit [r73364778d21a8d1959eeb27f2bf127c4d9e8aba2]
Author: David Kastrup <dak@gnu.org>
Date: Wed Oct 1 16:11:10 2014 +0200
Issue 630/1: Implement Grob_property_info::matched_pop
This can be passed a token returned from Grob_property_info::push and
will then only revert the matching push or nothing at all. This is used
to limit the fallout from internal property reversions that might not
match the original override because of an intervening property push/pop.
Labels: -Priority-Medium -Patch-push Fixed_2_19_16
Status: Fixed
Originally posted by: stans...@gmail.com
verified
Originally posted by: fedel...@gmail.com
(No comment was entered for this change.)
Status: Verified