Re: Fixing issue 786 (lyric extenders) again

[Joe Neeman]

On Mon, 2010-01-04 at 12:22 -0500, Chris Snyder wrote:
> > 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.

Your previous mail is asking a detailed question about code which
(AFAIK) few people on the list know much about. The only advice I can
offer is to pester the list more often than once a month.

> 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?

Do you mean a LyricEvent (ie. a Music object, which is created in the
parser) rather than a LyricText (ie. a Grob, which is created in an
engraver)? I don't know much about that part of the code, but it sounds
ok to me. Maybe it would be clearer, though, if you created a new music
type (EndExtenderEvent, for example).

Joe