\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.

... And that workaround doesn't work as expected!

<< { \grace b8 c c c c } \ { \grace s8 g g g g } >>

inverts voiceOne and voiceTwo.

I would expect that the real work around is to put

\new Staff or \new Voice in the appropriate place. (untested)

A simple workaround is to move the grace note out of the <<{...} \ {...}>> construct:

\version "2.13.4" \relative c'' { \grace b8 << { c c c c } \ { g g g g } >> }

An alternative solution that also works in the case where the second voice starts with a grace note is to explicitly add \voiceXXX commands after the grace notes:

\version "2.13.4" \relative c'' { << { \grace b8 \voiceOne c c c c } \ { \grace a \voiceTwo g g g g } >> }

Issue 667 has been merged into this issue.

There's a similar problem when the grace note follows \oneVoice immediately:

<< \new Staff << \new Voice { \voiceOne
e''4 e''4 e''4 e''4 | % 1 \oneVoice
\acciaccatura { d''16 [ e''16 ] } e''4 e''4 e''4 e''4 } \new Voice {
\voiceTwo f'4 f'4 f'4 f'4 | % 1 \oneVoice s1*4/4 }

> >

The acciacatura is stem-down and should be stem-up.

Issue 630 et al. Change confusion between property overrides and sets.

This appears to cure some but not all related problems since it makes the absurdly named make-voice-props-set and make-voice-props-revert (which are usually employed as a pair) actually paired.

http://codereview.appspot.com/5634049

Patchy the autobot says: LGTM. Regtest changes in quote-grace and property-grace-polyphony: both were wrong before.

Maybe I should have mentioned that this patch makes Documentation/ly-examples/tab-example.ly work as well. After all, that was the main motivation for it.

Things are not all honky-dory: the initial example (labelled as "wrong" by the reporter") works. The second example with balanced graces doesn't. I think that is a different issue likely connected with \. The example by Phil is rendered the same as in his report, but I don't agree with his analysis of it being wrong: if the acciaccatura is entered after \oneVoice, there is no reason for it not to pick its stem direction as it wants. If you enter it before \oneVoice, it retains its voiced direction.

Thanks for looking at this - it's a real pain to work around when it happens. However, the general principle, as stated by Gould, is that "Grace notes take up-stems, regardless of their position on the stave. An exception to this is where there are two parts on one stave, in which case the lower part takes down-stems".

Regarding comment #10: I totally don't get your point. Could you please point out where any change of behavior this patch introduces would disagree with the quoted description by Gould? What do you mean to imply with "However, ..."? I can't see your objection making any sense, exactly because of the cited desired behavior.

In comment #9 you said: "The example by Phil is rendered the same as in his report, but I don't agree with his analysis of it being wrong". It has downstems, despite there only being one part on the stave. It should not "pick its stem direction as it wants" - stems should be up.

Ok, now I see. But reordering lists in iteration so that context changes (and more importantly context starts) occur before a following brace is issue 34. This fix here is only concerned with grace starts not wreaking more havoc than the grace ends clean up. It fixes two regtests and at least one LSR snippet but is not a magical cure-all.

I don't think the problem with Phil's example is issue 34. The point is that graceSettings aren't iterated, they're applied instantly at the start of a timestep in the Grace_engraver. Before this engraver was added, this worked fine since all the set/unset processing was carried out via applyContext inside start(|stop)GraceMusic. Obviously \oneVoice sends a load of stream events which arrive later than the start of translation, so the stem direction override ends up being reverted.

Counted down to 20120212, please push.

Pushed as c4caf7d48d8a1b816ab3b007197f4dedaa6f7f75 to staging. This does not address all examples brought up in the discussion, but it does fix the original report. I think that most of the other problems would require the timing fixes that issue 34 is focused about.

This commit does weird things to my scores - it changes the behaviour of \oneVoice so that it doesn't return to neutral directions; instead, it goes back to the previous \voice* setting:

\version "2.15.30"

\relative c''' { \voiceOne c2 \voiceTwo c2 \voiceOne << { c2 c } \new Voice { \voiceTwo a2 a }

> \oneVoice %ends up as \voiceTwo c,,2 c }

This is actually a bit of a dilemma here: the previous behavior was to do a revert+override when setting voice settings, and a revert afterwards. For things like graces, which are intended to override the settings temporarily, the initial revert was wreaking havoc, and omitting the initial revert makes sense. However, if one considers voiceOne and oneVoice as commands establishing an absolute behavior, the pop-before-push semantics make some sense as well.

I will recheck my approach and see whether it is possible to differentiate this better.

Introduce separate make-voice-props-override in order to fix issue 630 fallout

http://codereview.appspot.com/5674073

Patch is up. This should revert to the old behavior except where reverting is clearly wrong because we revert.

While it would appear that the patch now is the right thing to do with regard to override/revert pairings, it turns out that the smaller changes it now causes do not actually affect this issue at all. I'll commit the patch after Patchy is ok with it, but this means that the issue remains open in the same state as it started with, and possibly some unrelated problems being improved.

I just stumbled upon the situation described in comment #2. Given that it is apparently quite hard to fix I wonder whether it makes sense to document the workaround.

Eluze reported a similar problem here:

http://lists.gnu.org/archive/html/bug-lilypond/2013-02/msg00055.html

which I was able to reproduce using version 2.17.11

Eluze reported as follows:

with

\relative { \voiceOne \grace a'8 c4 c c c }

the stem direction of the following notes is wrong

this doesn't happen if the grace is not the first note or by repeating \voiceOne after the grace.

I didn't find an exactly matching bug report

Eluze

This actually appears significantly different from issue 34 and is most likely the direct consequence of

commit 4f795f5a103f6bf1c3a5590302ba54a361186524 Author: Han-Wen Nienhuys 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.

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.

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.

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

Reinstate acciaccatura in tab example removed during issue 2480

http://codereview.appspot.com/150440043

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.

Move override in flags-straight-stockhausen-boulez.ly

http://codereview.appspot.com/150440043

According to old archived regtests, property-grace-polyphony broke between version v2.4 and v2.6.

Patchy the autobot says: passes tests. Now the only changed regtest output is property-grace-polyphony and it is fixed as compared to previously.

passes a make doc too (if that helps)

Issue 4144 has been merged into this issue.

Patch on countdown for October 9th

Patch counted down - please push

Pushed to staging as commit 649bfd6a9ad3d32eb17b460103464a8d997bf35b Author: David Kastrup Date: Fri Oct 3 00:34:09 2014 +0200

Issue 630/6: Move override in flags-straight-stockhausen-boulez.ly

commit af941ebfc956af0a47341e29552d21af153ca961 Author: David Kastrup Date: Fri Oct 3 00:01:40 2014 +0200

Issue 630/5: Reinstate acciaccatura in tablature example

This was removed with commit 2817ef1228cecd8b275fd666e0b5ba1bbd9406ce in
version 2.15.38 since issue 630 was just too hard to work around.

commit 99a85ca39f3a7a6f717ba06a48ef0ba70f842177 Author: David Kastrup 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 6a023cc84879573668eaf9120bb13b93cfdf12cb Author: David Kastrup Date: Thu Oct 2 16:13:51 2014 +0200

Issue 630/3: Let Grace_iterator produce a GraceChange event

commit 7d737869f67f101dcc2c602a0fcccdfb7d0bd4a4 Author: David Kastrup Date: Wed Oct 1 16:55:07 2014 +0200

Issue 630/2: Let grace_engraver only pop grob properties it pushed itself

commit 73364778d21a8d1959eeb27f2bf127c4d9e8aba2 Author: David Kastrup 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.

verified