lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Any ideas what is happening here?


From: David Kastrup
Subject: Re: Any ideas what is happening here?
Date: Thu, 04 Nov 2021 11:23:55 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Dan Eble <nine.fierce.ballads@gmail.com> writes:

>> On Nov 3, 2021, at 19:20, David Kastrup <dak@gnu.org> wrote:
>> 
>> Dan Eble <nine.fierce.ballads@gmail.com> writes:
>> 
>>> On Nov 3, 2021, at 18:40, David Kastrup <dak@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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]