Plans for changing chord repeat implementations

[David Kastrup]

Hi,

the default chord repeat code contains stuff like

   ;; If previous-chord has an length property, then it means that it
   ;; has been processed by a music iterator.  In other words, the chord
   ;; has been memorized from an other music block, which is certainly not
   ;; what the user has intended, as anywy the result will be buggy.
   ;; In that case, raise a warning.

Ok, this is all sort of madness.  Music functions are _free_ to change
their arguments and quite a number of them do, not just \relative.  It
does not do to keep just a pointer to a chord since by the time one
actually uses it, it can be trashed in a number of ways.  Having a music
iterator run over it is just one of many possibilities.  Copying the
whole chord just because it might get used is expensive and unnecessary.
_If_ we try doing this in the parser (and I don't see a really good
other place that is reasonably convenient for the user), we should not
copy the chord, but just the list of pitches.  After all, this is what
the documentation of q as far as I can see _claims_ is copied.  There is
the added complication that a chord can contain more than just pitches:
it is possible to have drum types instead.  And of course anything
sneaked in as rhythmic events via music functions.

Of course, when running through \relative or a similarly applied music
function that runs over a whole expression in one go would be able to
work just with pointers.

I have taken a look at the regtests and rest of LilyPond.  The only
cases where q is being used is either inside of \relative or explicitly
for testing absolute mode.

So I lean towards removing repeated chord tracking from the parser
altogether.  You would need to explicitly run a music function for doing
the last chord substitutions.  to_relative could be made to set a flag
when encountering a repeated chord, so that \relative would
automatically run the repeated chord substitutor at the end when it was
required.

That would mean _no_ problems with chords changing under the parser,
_no_ need to extract pitches or other information just-in-case, no input
syntax change when used simultanously with \relative, and no performance
impact when the user does not actually use that feature.  It would also
reopen the door to extract more than just pitches.

The bad news is that absolute pitch friends would have to call the \q
function (any better name for it?) explicitly.  Since q is an input
convenience, and relative pitch is also an input convenience, I don't
think that there would be much of an affected user base.
Machine-generated output would rarely have to use q.

-- 
David Kastrup