David Kastrup <d...@gnu.org> writes: > 2) do it in a specific music function either explicitly called, or > called automatically at an appropriate time. > > This is totally straightforward and controllable. It also means that it > is ok to work with a reference to the previous chord since no arbitrary > processing stages (like in the parser) will intervene between taking the > reference and using it. It also means that we can _replace_ the > ChordRepeat event with an EventChord, meaning that any subsequent > processing never gets to see a chord repetition. > > That means that "legacy" music functions of the user don't require > changes to accommodate chord repetitions: it is easy to make sure that > they never get to see them. After \relative seems to be a good time to > call \q automatically (one could be cute and call it \absolute instead, > meaning that a user wanting to use q should have had his music passed > through either \relative or \absolute). > > 3) do the chord repetition right before iteration time (iteration itself > is too time-centric rather than order-centric to work well).
It would seem like the combination of an explicitly callable function together with putting it into toplevel-music-functions (where things like {xxx\\yyy} apparently are also resolved) should do the trick in a suitably backward-compatible manner. I guess the performance impact of another pass through the music, given suitable callbacks, should be small. It would be possible to let q set a parser variable that will optimize this pass away when unset. The drawback would be that ChordRepeat events entering via different channels (#{ <c e g> q #} uses its own parser, and generation by Scheme is also possible) would not count then. Ok, I guess I have my implementation strategy then. Hard-earned 70€ or whatever the bounty was, but I think I will feel reasonably sure that the results will not come back to bite me. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel