lilypond-auto
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lilypond-auto] Issue 34 in lilypond: Grace synchronization


From: lilypond
Subject: Re: [Lilypond-auto] Issue 34 in lilypond: Grace synchronization
Date: Sat, 30 Jun 2012 20:31:51 +0000


Comment #26 on issue 34 by address@hidden: Grace synchronization
http://code.google.com/p/lilypond/issues/detail?id=34

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]