David Kastrup <[email protected]> writes: > David Kastrup <[email protected]> writes: > >> Dan Eble <[email protected]> writes: >>> >>> 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. > > To wit: I am using skipTypesetting in connection with some counter > juggling in \applyContext to split a MIDI into pieces at places > indicated in the score. One start of a piece is in a \repeat volta in > the first volta. There is \articulate (likely not involved) and > \unfoldRepeats . The respective \applyContext call in the repeat body > is guarded by \volta 1 (which is not really according to the examples in > the documentation but matches the doc string of \volta itself) but the > piece still gets split in both repeats. The minimal examples I tried to > construct under simpler circumstances all work as written for > introducing material constrained to one volta (good work, by the way). > > The workaround is obviously a copy&paste job hand-expanding that > particular repeat volta. That would mess with the bar numbers, but > currently we don't have a Bar_number_performer that would convey the > actual bar numbers into MIDI so right now that difference is > academical.
unfold-repeats-fully works as the core of the workaround for now (I don't use \relative, this being mainly a drum score and the timpani already being at an octave easy to write for, so I don't encounter the main problem with using unfold-repeats-fully). I'll try to get out a more relevant report for the actual problem I am seeing in due time. -- David Kastrup
