> Yes, I am top-posting
I notice that issue 786 was just marked as critical. I sent the
following message to -devel four weeks ago but never received a
response. I'd appreciate advice on how to write messages that are more
responder-friendly.
Chris Snyder wrote:
Issue 786, which was caused by a patch I submitted back in March, was
recently re-opened with another case of an extender being completized
too early. Looking at the example, it's easy to spot what's going on.
The fix, however, looks to me to be less straightforward.
Some background:
The original patch fixed an issue where an extender would go too long
(sometimes to the end of the score) when the lyrics ended before the
associated voice. This was because extenders were only completized when
the next event in the Lyrics context came along, which would never occur
if the Lyrics block ended with an extender. My original patch added a
check to see if the voice was in a melisma and to completize the
extender if not.
One problem this caused (original issue 786) was with manual melismata,
which the melisma_busy(voice) function doesn't know about (and can't -
it doesn't know about Lyrics contexts at all, nor should/could it, since
multiple Lyrics contexts can be associated with one voice). This was
fixed by changing the Lyric_engraver to add empty LyricText objects. The
Extender_engraver checks both melisma_busy and for the presence of an
empty LyricText object, and only completizes the extender if neither is
true (as well as another check to fix issue 800).
The case that caused issue 786 to be reopened, however, poses yet
another problem. It is more general than just happening with beamed
notes - I've verified the same behavior with slurs and ties as well. It
happens whenever an automatic melisma (beam, slur, tie) is followed by a
manual one (underscore in Lyrics). Looking at the checks I added, it's
obvious what's happening: On the last note of the automatic melisma,
melisma_busy returns false, but the empty LyricsText object won't occur
until the next moment, so the Extender_engraver thinks it should
completize the extender.
Under the scheme as it exists now, the Extender_engraver would have to
somehow check for an empty LyricText object occurring in the future.
This doesn't seem to me to be the correct approach.
Alternatively, I've thought of another solution that seems to be more
elegant than this growing list of checks for various cases: what if the
parser created an empty LyricText object at the end of each Lyrics
block? That would solve the original issue I fixed back in March in a
way that would allow us to revert that part of the Extender_engraver to
the way it was before my original patch. Before I try to learn how the
parser works, does this seem like an acceptable approach?
Thanks,
-Chris
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
