[Top][All Lists]
[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.