David Kastrup <d...@gnu.org> writes:
>> David mentioned two issues: using `<<...>>` top-level and using
>> unpitched notes.
>>
>> Consider the following not-quite-as-minimal example:
>>
>> %%%%
>> \version "2.19.82"
>> music = { \once \offset length 5 Stem c'4 c'4 }
>> \new Staff { c'4 << \music \music >> c'4 }
>> %%%%
>>
>> Near as I can tell, the thing that makes the difference here is the
>> \once. If you omit the \once (which means the stem length change
>> persists), then you can at least get it to compile.
>
> That's plausible: \once incurs action both at the current timestep and
> in preparation for the next timestep. If the context is in bad shape
> for the latter (and the context is not slated for continuation here),
> that could trigger the trouble.
Actually, <<>> is a red herring as is \once. The following is the same
crash:
%%%%
\version "2.19.82"
music = \temporary \offset length 5 Stem
\new Staff { \music \music c'4 }
%%%%
The point is that \offset identifies itself in the overrides in order to
not cause infinite recursion. The way in which it does that survives
across music copies, so if you do it twice via copied music, you get the
infinite recursion crash.
Without \once or \temporary prefixes, the first override gets removed
before the second one is applied, so there is just one override active.
With \once, the first override gets removed before the second one is
applied unless both occur at the same moment.
Here is an even shorter one (I think this one does not even involve
copying music):
%%%%
\version "2.19.82"
{ \repeat unfold 2 \temporary \offset length 5 Stem c'4 }
%%%%
--
David Kastrup
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
