Re: engraving ends too early

[James Lowe]

On 25/05/15 08:58, David Kastrup wrote:
> Dan Eble <address@hidden> writes:
> 
>> % 2.19.20 does not engrave the lyrics and stops engraving the vocal
>> % staff before the end.  (Compare to 2.18.2.)  I haven’t tested MIDI.
>>
>> \version "2.18.0"
>> \include "english.ly"
>>
>> vocal = \relative c'' { R1 | f2 c }
>>
>> % adding the skip makes 2.19.20 work
>> accomp = \relative c'' { c1 %{ s1 %} }
>>
>> \score {
>>   <<
>>     <<      
>>       \new Staff <<
>>      \new Voice = "vocal" { \vocal }
>>       >>
>>       \new Lyrics <<
>>      \lyricsto "vocal" { \lyricmode { La la } }
>>       >>
>>     >>
>>     
>>     \new Staff <<
>>       \context Voice = "obligII" { \accomp }
>>     >>
>>   >>
>> }
> 
> MIDI will be the same: this is an iterator issue so all outputs will be
> affected similarly.
> 
> This is obviously a consequence of the fix for issue 2010 (and 702 and
> 1551).  This fix is a rather heavy-handed one.  The problems it cures
> are arguably weirder and harder to work around than the stuff that now
> terminates early: the original problem was tied to stuff sticking around
> for too long even when it terminated at the same time as something else,
> while the current problem is stuff terminating early along with other
> stuff.
> 
> I've spent several weeks on this one and have not been able to find a
> nicer fix.  That does not mean that there isn't one: I did not really
> figure out the real cause of the problem to my satisfaction.
> 
> There are several elements involved, my guess is the following:
> a) the first context in a group of << ... >> is kept alive while the
> rest still has action.
> b) there are situations where a context is kept alive with the only
> remaining "action" in his group is an associated Lyrics context that has
> not registered the nominal death of its associated context which in turn
> is artificially alive until the Lyrics in the group die.
> 
> Now the current fix relies on the associated lyrics and the controlling
> context being in the same << ... >> construct.  Clearly that
> assumption/requirement is not met too often for comfort.
> 


https://code.google.com/p/lilypond/issues/detail?id=4419

has been created to keep track of this.

James