Re: Summary of \relative { q } ... analysis.

[David Kastrup]

David Kastrup <address@hidden> 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