Re: Multi_measure_rest::get_rods (): I am not spanned!

[David Kastrup]

Dan Eble <address@hidden> writes:

> *** Unexpected Output ***
> programming error: Object is not a markup.
> This object should be a markup: ()
> programming error: Multi_measure_rest::get_rods (): I am not spanned!
>
> These are the same messages as in 
> https://code.google.com/p/lilypond/issues/detail?id=1291 (Oct 4, 2010).  I 
> don’t know whether this is a new problem or just a new way to reproduce that 
> same old problem.
>
> *** Input ***
> \version "2.19.15"
>
> chordNames = \chordmode {
>   f1 | %{nothing in final measure%}
> }
>
> leadNotes = \relative {
>   f'1 | R1
> }
>
> words = \lyricmode {
>   Blah
> }
>
> <<
>   \new ChordNames {
>     \chordNames
>   }
>
>   \new ChoirStaff
>   <<
>     \new Staff <<
>       \new Voice = "lead" { \leadNotes }
>     >>
>
>     \new Lyrics <<
>       \lyricsto lead { \words }
>     >>
>   >>
>>>
>
> *** Commit ***
> For my input, these messages appeared after this commit:
>
> commit b12ee555e33d483eed0832d8502ad7a282ef9796
> Author: David Kastrup <address@hidden>
> Date:   Mon Oct 6 00:31:58 2014 +0200
>
>     Issue 2010: \lyricsto may turn into a voice-mangling zombie
>     
>     The problem here was that the simultaneous iterator might keep
>     rerhythmed lyrics around when the associated voice has died already,
>     blocking the simultaneous iterator.  The solution is that when removing
>     the last regular iterator to remove all remaining lyric-combined
>     iterators at the same time.

I have not analyzed this explicitly.  I consider it conceivable that the
"lead" context is being removed after R1 has had its initial processing
but before it has had a chance to complete.

Make no mistake: the solution to issue 2010 is heavy-handed, killing
possibly valid contexts in weird situations where the correct behavior
would let them continue.  However, the killed context here should be the
associated lyrics context which is not the core context this bug report
is concerned with.  So I consider it likely that the behavior change
witnessed after the fix to issue 2010 does not create the shown problem
but merely is a somewhat contorted way to arrive at it.

Here is one shorter recipe producing pretty much the same obscure error
messages (as well as others)

{ R1*1/2 }

Chances are that cleaning up the error messages for this shorter example
to the degree where only messages making some sense remain, issue 2010
will no longer come into play for the particular lyricsto example.

-- 
David Kastrup