Dan Eble <nine.fierce.ball...@gmail.com> writes:
>> On Nov 3, 2021, at 19:20, David Kastrup <d...@gnu.org> wrote:
>>
>> Dan Eble <nine.fierce.ball...@gmail.com> writes:
>>
>>> On Nov 3, 2021, at 18:40, David Kastrup <d...@gnu.org> wrote:
>>>>
>>>>
>>>> My use case is something different entirely and it does not work as
>>>> expected. This may or may not be a relevant minimal example for my use
>>>> case (no idea) but is weird enough to suggest something's off.
>>>>
>>>> {
>>>> \repeat volta 2
>>>> {
>>>> c'1
>>>> \volta 1 \set Timing.baseMoment = #(ly:make-moment 1/4)
>>>> e'1
>>>> }
>>>> }
>>>
>>> I have no time now, but I hope I can take a look in a few hours.
>>> Maybe the iterator for \volta should be doing something different with
>>> its context. I very vaguely recall that the NR tells of a known issue
>>> involving repeats and contexts.
>>
>> Note: If you include ‘\relative’ inside a ‘\repeat’ without
>> explicitly instantiating the ‘Voice’ context, extra (unwanted)
>> staves will appear. See *note (lilypond-usage)An extra staff
>> appears::.
>>
>>
>> Not really related as far as I can see. There is no \relative here, and
>> at the problematic moment, a Timing context most certainly exists and is
>> visible, and the current context is already instantiated as a Voice
>> context. You can put \new Voice or \new Staff around the whole repeat
>> or its body without change.
>
> Using \tuplet 1/1 instead of \volta 1 causes the same problem.
>
> Nesting the \set within <<>> or {} makes the problem go away. Does
> that serve as a work-around in your use case?
There is an abundance of << >> (due to tags being in play) already. My
problematic code uses utility functions using ly:context-output-def; the
"minimal example" just uses some similar elements until something
strange appears, but the strangeness is not really in any remotely
recognisable way related to the problem I am seeing.
So I cannot really "reduce to a minimal example" sensibly until
ly:context-output-def has made it upstream which will be in a few days.
--
David Kastrup
