[Top][All Lists]

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

Fixing issue 786 (lyric extenders) again

From: Chris Snyder
Subject: Fixing issue 786 (lyric extenders) again
Date: Mon, 14 Dec 2009 14:28:51 -0500
User-agent: Thunderbird (X11/20090817)

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?


reply via email to

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