#34 Grace synchronization

[Anonymous]

Originally created by: *anonymous

Originally created by: *anonymous

Originally created by: hanw...@gmail.com

Fix problems with synchronization of different staves where one staff has a
grace note, and the other one doesn't, causing key/time sig changes,
\prpoerty settings, barlines etc. to go out of sync. 

[Google Importer]

Originally posted by: v.villenave

A related bug report from Eliot Bates:

The instrumentName doesn't appear on the second staff.

\version "2.11.41"

<<
  \new Staff { \set Staff.instrumentName = "lavta"
    \acciaccatura a'32 a'1 }
  \new Staff { \set Staff.instrumentName = "udu"
    a1 }
>>

(see also #25)
IMHO this is a Defect, not an Enhancement (even though we can tag it as Postponed).

[Google Importer]

Originally posted by: v.villenave

% Another report from David:

\version "2.11.47"

\score {
  \context Staff <<
    \clef "F"
    \relative c {
      \appoggiatura { c8[ d e] } f4 g a b
    }
  >>
}

[Google Importer]

Originally posted by: v.villenave

For whoever is going to work on this issue, please also have a look at Issue 630.

[Google Importer]

Originally posted by: gpermus@gmail.com

Whenever anybody looks at this, here's another fun case:

% order of commands can result in beamed or unbeamed material

\version "2.13.2"
\relative c' {
  % these 3 lines result in no beaming later
  \partial 8
  \grace ais8
  b8

  % these 3 lines would result in proper beams
  %\grace ais8
  %\partial 8
  %b8

  % has no effect; here just for show.
  \autoBeamOn
  c c s2.
}

[Google Importer]

Originally posted by: harmathdenes

May I ask why this is Low priority? This is a serious issue: consider a huge
partition beginning with grace notes... I can't achieve correct output even after
putting grace skips in the beginning of each part; and even if I could, it would be a
nightmare to maintain.

[Google Importer]

Originally posted by: graham...@gmail.com

It's low priority because nobody wants to work on it.

If you're interested in helping out, please do!  If you're not willing to work on it
yourself, then realise that we have exactly the same reasons you do.

[Google Importer]

Originally posted by: harmathdenes

I understand that this would be a tremendous amount work, since handling grace notes this way seems like a fundamental design decision. Unfortunately, although a developer myself, I'm not at all familiar with the LilyPond codebase, and do not have the resources to even dive into it this deep, not to mention correcting it.

(In my concrete previous example, I had put the grace skip before the key signature, hence the incorrect behaviour; now the output is correct, but this shows just another non-intuitive caveat with grace note synchronization!)

[Google Importer]

Originally posted by: percival.music.ca@gmail.com

Fair enough, but nobody else has the resources to dive that deep. Believe me, we know about the bug. But unless anybody steps forward to tackle it, adding more noise only serves to annoy people.

[Google Importer]

Originally posted by: percival.music.ca@gmail.com

Issue 1052 has been merged into this issue.

[Google Importer]

Originally posted by: arnonoki...@googlemail.com

I got almost all thingies i experienced in the grace note oddities' realm with a construction like:

s64 \grace c8 h2*31/32

instead of:

\grace c8 h2

Given that nobody is able or willing to provide a "real" solution, wouldn't it be a sufficient temporary solution to teach the parser to apply those tricks by itself instead of us manually?

[Google Importer]

Originally posted by: Carl.D.S...@gmail.com

Issue 1302 has been merged into this issue.

[Google Importer]

Originally posted by: paconet....@gmail.com

Re: comment #4 both cases now produce the same output.
Examples on #1 and #2 still valid.

[Google Importer]

Originally posted by: carlo.stemberger@gmail.com

Debian issues #153782 and #153784 are forwarded here.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=153782
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=153784

Regards,
Carlo

[Google Importer]

Originally posted by: reinhold...@gmail.com

I did a little digging and the issue is that all \set commands (like the clef) and all other events (like KeyEvent) are treated as if they occurred together with the first note (and that problem lies deeper than the Sequential_iterator's handling of grace notes!). I.e. if you have:
Voice 1: \clef "bass" \grace c8 d4
Voice 2: \clef "bass" d4

Then in Voice 1, the clef properties (clefGlyph and the like) will be set at moment 0G-1/8, while in Voice 2, they will be set only at moment 0G.
Similarly, all key events will be assigned the moment of the first note...
Now, the iterators and then the engravers go through the music one moment at a time, so the order of things is:
-) moment 0G-1/8 : only voice 1 creates a clef and the grace note
-) moment 0 : voice 1 creates the d4, while voice 2 changes the clef and creates a d4.

However, in my eyes we need to distinguish the events at each moment. Basically, we have three different types of events:

1) events that should be processed at the very beginning of each moment (before grace notes are handled)
2) grace notes (i.e. notes that appear before the real content of the moment), possibly also including some \set command, which should not mess up things
3) normal notes

In other words, we need to find a way to process key/clef/barlines (in particular all SetEvents) etc. before all grace notes. One approach might be to assign a moment like 0G-inf to them, so they will be processed before all grace notes.

Or does anyone have a better idea where to start?

Cheers,
Reinhold

[Google Importer]

Originally posted by: dak@gnu.org

Well, if we have
\grace c8  \clef "bass" d4
then the clef needs to be at 0G after all.

Instead of -inf, one could try #f (no grace timing) unless that causes too many changes/problems.  -10000 is likely to be supported and sufficient.

[Google Importer]

Originally posted by: reinhold...@gmail.com

Am Donnerstag, 21. Juli 2011, 08:05:22 schrieben Sie:
> Comment #15 on issue 34 by d...@gnu.org: Grace synchronization
> https://code.google.com/p/lilypond/issues/detail?id=34
>
> Well, if we have
> \grace c8  \clef "bass" d4
> then the clef needs to be at 0G after all.

Of course, the comment about SetProperty events and the like not messing up the grace part is true for the main part, too.
Basically, the iterator would work like:
1) Start with grace timing G-inf for each moment and use that for all prefatory events
2) If a grace event is encountered, start the normal grace timing (as we have it now)
3) any normal note (main part) resets the grace timing to G0.

I'll have to figure out where the exact moments are assigned, though. I have the suspicion that the sequential-iterator.cc is responsible, but I don't have such a deep insight into the iteration process yet.

In your example, the c8 would get a grace timing G-1/8 and start the nomral timing, so the \clef would get grace timing G0.

> Instead of -inf, one could try #f (no grace timing) unless that causes too
> many changes/problems.

nice idea.

> -10000 is likely to be supported and sufficient.

Maybe, but to me as a mathematician, using a finite number to indicate infinite is sub-obtimal...

Cheers,
Reinhold

[Google Importer]

Originally posted by: reinhold...@gmail.com

Comment by Keith O'Hara on bug-lilypond:

> However, in my eyes we need to distinguish the events at each moment. 
> Basically, we have three different types of events:
>
> 1) events that should be processed at the very beginning of each moment 
> (before grace notes are handled)
> 2) grace notes (i.e. notes that appear before the real content of the 
> moment), possibly also including some \set command, which should not mess 
> up things
> 3) normal notes
>
> In other words, we need to find a way to process key/clef/barlines (in 
> particular all SetEvents) etc. before all grace notes. One approach might 
> be to assign a moment like 0G-inf to them, so they will be processed before 
> all grace notes.

I think that is a promising approach.  I looked through the code thinking about
this issue two days ago, and began to look for a way to default-initialize the
grace_part_ of a Moment to something that would sort before any defined value
of grace_part_.  I do not know enough Scheme to know if Rational grace_part_ =
-1 / 0 is guaranteed to work as -inf.

It looks like most events should have effectively -inf for the grace_part_ of
their timing. 

The new method would need to take over the job that create_grace_fixup_list()
tries to do.  I am still figuring out how the list is created.

[Google Importer]

Originally posted by: dak@gnu.org

I've had another musing.  My proposal of using -inf as normal grace timing basically shifts just one problem class to another since some things need to happen before graces in other contexts, some after.

So I thought about this: we have a start-of-timestep callback in engravers, and event callbacks and end-of-timestep.  Now what we actually want when a grace is in a parallel context but not in ours, is to have our start-of-timestep callback called before the grace in the other context starts its event callbacks, and our end-of-timestep called afterwards.  And actually, if there is a preceding event in our own graceless context, its end-of-timestep is to be called _afterwards_ as well.

So with a grace, I tend to consider it reasonable to have a start-of-timestep for the next event in sequence called before the end-of-timestep of the preceding event in the same context is called when a grace occurs in a parallel context.  Possibly (but less sure about that) even when the grace occurs in one's own context.  The context-moment should likely reflect the grace timing, as if one had had a spacer grace in one's own voice.

That way typical start-of-timestep actions like creating a new context or establishing a new clef or setting context properties or so will happen before graces in parallel voices.

[Google Importer]

Originally posted by: k-ohara5...@oco.net

>  using -inf as normal grace timing basically shifts just one problem class
> to another since some things need to happen before graces in other contexts,
> some after.

Reinhold's suggestion was that BarLines and such get 0G-inf while events that come after any parallel graces get 0G0.

I looked through the iterators and made notes for how this would work, <http://codereview.appspot.com/5132042/>   One conceptual change is that the grace part of event timing is a *request* to start early, which can be honored if the requested moment is still available.  Then it appears that the existing system with simultaneous-music and sequential-music iterator can handle the issues with parallel contexts.

I chip away at this for a couple hours every couple months.  As I recall the most recent task was cleaning up the complexity of simple_music_iterator from processing its events twice.

[Google Importer]

Originally posted by: dak@gnu.org

One problem is that a context property setting in a different context has to be processed at 0G-inf even if followed but not preceded by a grace note in this context.

When replaying notes, the end of the preceding note in the current context is moved backward in time by a grace, but not the end of preceding notes in other contexts.  But setting a property in other contexts _is_ moved backward if there is no grace note preceding in the current context.

Basically, I don't see that in-time ordering of events can be held up across timestep-starting and timestep-finishing events.

[Google Importer]

Originally posted by: janek.li...@gmail.com

(No comment was entered for this change.)

Labels: -Priority-Low

[Google Importer]

Originally posted by: janek.li...@gmail.com

(No comment was entered for this change.)

Status: Accepted

[Google Importer]

Originally posted by: dak@gnu.org

Phooey.  Moments are used for a number of things: for moments themselves, for timespans between moments, and sometimes for accumulating timespans.  Basically, there is a bit of reliance that the usual arithmetic laws will hold.  So it is not really overly feasible to squeeze -inf grace as a somewhat neutral element into the arithmetic and hope that things work out.

With regard to property changes etc, it seems unfortunate not to be able to distinguish the time before any grace and the time after graces.

My personal favorite would be to use #f and 0 for "before" and "after graces".  However, moments don't contain SCM, but rather Rational members.  Personally, I think that the whole Rational class (and the respective conversion problems) would benefit from getting scrapped and getting replaced just by Scheme rationals.

Doing that just internally (namely, replacing only the implementation of Rational) would be somewhat inefficient since it would convert things back and forth from Scheme unnecessarily.

Anyway, that is a different topic.

In the mean time, playing arithmetic games would not appear to help, so one should probably try fixing up the program's logic if feasible: after all, most of the work _is_ in place for working with graces.

I can't help myself, but I find the following comment in grace-iterator.cc to be on the less convincing side:

void
Grace_iterator::process (Moment m)
{
  Moment main;
  main.main_part_ = -start_mom_.grace_part_ + m.grace_part_;
  Music_wrapper_iterator::process (main);

  /* We can safely do this, since \grace should always be inside
     sequential.  */
  descend_to_child (child_iter_->get_outlet ());
}

While I don't understand graces (yet?), comments like that make me shiver.

[Google Importer]

Originally posted by: k-ohara5...@oco.net

A Moment comprises a main_part and grace_part.
The main_parts of sequential moments typically add, but the
grace_parts generally should not add.   The code either treats
the  parts separately, or deals in Moments that have only grace_
or only main_ parts.  There is no documented meaning for two
successive Musics with grace timing such as
{\grace a8 \grace b4 c2}.

I suggest that the grace_part should not participate in
arithmetic between Moments.  When the sequential iterator
passes a \grace{} it can set the grace_part to zero.

Each Music (whether a note or \bar or {...} or <<>> or \grace)
reports its requested start_mom() (always a negative grace timing)
and its get_length() (always a positive main timing).

I suggest that start_mom() be treated as a /request/ for the Music
to start before the current main_part_.  For example, in
   { \key g\major \grace c8 \clef alto d1 }
if the \key requests a start_mom() of grace = -inf, that request
could be granted and the key signature printed before any (possibly
longer) graces on other staves.  A similar request for \clef must
be denied, because the clock has already advanced to grace = 0.

Then the sequential iterator can advance based on the current
time and the next Music's request.  Currently, the iterator looks
ahead for up-coming grace timing, stored in the grace_fixups list,
which is tricky and does not look at simultaneous music sequences.

[Google Importer]

Originally posted by: k-ohara5...@oco.net

(No comment was entered for this change.)

Labels: Patch-abandoned