Chord repetition: \relative mode

Chord repetition: \relative mode

Introduce a new RepeatedChord music type, which element property is
the copied chord (as produced by the chord repetition function).
Define a relative callback for repeated chords, which avoids
octaviation of repeated chords, by modifying the first note octave
before applying the octave relativization.

[nicolas.sceaux, 2009-12-03 10:56:31]

Hi,

Here is a patch to make chord repetition work in \relative mode.
As I'm not sure how exactly music translation works, might someone comment the
RepeatedChord music type definition, and the relative callback?
In particular, I don't know what the RepeatedChord types property should be.
I basically copied the type definition from an other music wrapper (i.e. an
object with a music element property, like overrides), and added a new relative
callback for handling repeated chord.

Nicolas

[nicolas.sceaux, 2009-12-06 17:23:13]

Hi,

I've uploaded a second patch set, which introduces a chord memorization
function.

When dealing with a simple_chord_element (simple notes, rests, etc) or a
note_chord_element (chord with several notes), the parser updates the memorized
chord by calling a user-settable memorization function (see parser.yy).

In this implementation, two memorization functions are provided: a default one
which makes no check (memorize whatever element is given to it), and an other
one which memorizes chords that have more than one note. See
ly/chord-repetition-init.ly.

The default chord repetition function, in ly/chord-repetition-init.ly, has also
been improved: remove cautionary accidentals, check whether a chord has been
memorized in the same music block, fix origin of the repeated chord.

Example (when using the memorization function for chords with more than one
note):

lilypond /Users/nicolas/tmp/bug.ly
GNU LilyPond 2.13.9
Traitement de << /Users/nicolas/tmp/bug.ly >>
Analyse...
/Users/nicolas/tmp/bug.ly:9:12: No memorized chord in music block before chord
repetition
{ d''2\rest 
            q4 q8 d'' }

[dak, 2009-12-06 19:30:03]

On 2009/12/06 17:23:13, nicolas.sceaux wrote:

> When dealing with a simple_chord_element (simple notes, rests, etc) or a
> note_chord_element (chord with several notes), the parser updates the
memorized
> chord by calling a user-settable memorization function (see parser.yy).

I think it is the wrong way to go if notes can only be guessed if you know what
user-settable memorization function is in effect.  We should not sacrifice
readability for the sake of saving a few keystrokes.

q should have fixed, simple, understandable semantics even if that means that it
saves fewer keystrokes in border situations.  Having its meaning change on
demand, in particular when this might affect \relative octaves, is a bad idea.

Write-only music is not a good idea.

[nicolas.sceaux, 2009-12-06 21:11:25]

Le 6 déc. 2009 à 20:30, dak@gnu.org a écrit :

> I think it is the wrong way to go if notes can only be guessed if you
> know what user-settable memorization function is in effect.  We should
> not sacrifice readability for the sake of saving a few keystrokes.

This is a valid objection, but which kind of music elements should be
copied by q, then? (which was my question in the first place)
If people think that e.g. chords only should be memorized, then I'm fine
with that.  The implementation will be easier.

On the other hand... which ratio of users might ever change the behavior
of chord repetition memorization?  I don't really think that readability
might suffer, as long as the default is the most convenient.  For instance,
users can also completely change the note names, this is possible being 
given the interface for setting note names, but the fact that it is possible
does not by itself cause readability problems.  It could be even adviced to
change the repetition shortcut when changing the memorization function, to
avoid readability problems (or at least warn the reader that something
unusual happens there).

As a LilyPond user who maintains more than 100'000 lines of LilyPond code,
what I cherish the most about LilyPond is its extensability.  Is it really
needed here, I don't know yet.

Nicolas