Comment #30 on issue 1110 by d...@gnu.org: Wrong octave of repetition chord
with \relative and #{ #} syntax
http://code.google.com/p/lilypond/issues/detail?id=1110
Now since issue 2240 aka 2270 is on the countdown, it makes some sense to
think about this one again. We now have the situation that EventChord is a
satisfactorily reliable indicator of an actual chord.
I see two ways to deal with this issue now.
a) have q work in the parser (as it does now), let \relative completely
reconsider the relation between q and its preceding chord. This is
actually pretty ugly.
b) have q never record any pitches (it won't be fazed by \relative then).
Instead, the iterator for the repeated chord fills in the pitches. The
question is just where it gets them from. It can't bother the EventChord
iterator for that since in the case of << { c <c d e> } q >> the
event-chord-iterator is called later than the corresponding repeated chord
iterator. Basically we need to comb through the whole expression that is
going to be iterated, and fill in the repeated chords.
\relative does its respective work on demand. How can we avoid unnecessary
work? Do it on demand as well?
\repeatChords \relative c' << { c <c d e> } q >>
Then the user would be responsible not to apply \relative after
\repeatChords...
That would be a very straightforward solution without extra cost if you did
not actually use the feature. Normally it would be sufficient to put the
contents of your \score into a single \repeatChords. I doubt that this
will make people happy...
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
