Graham Percival wrote:
> ...lilypond acts according to the docs,
Certainly true.
> so it's not an official "bug".
There is a flaw in the way the feature works that
prevents it from providing its intended functionality
in many cases. In all of the projects I have worked
on over the years, that is
Paul Scott wrote:
> Here are some examples of chords of varying lengths:
> c1*3 d4:m7 g4*3:7 c1 a4*3:7.5+ a4:7
Yes, that's nice. But I find it prone to errors. It
takes me a lot of work to get that kind of thing
right. Chord change mode makes it so easy!
Another source of stubborn errors in lead
Paul, thanks for your attention to this issue.
Paul Scott wrote:
> If you can carefully describe what you want
> different than the current behavior I can
> help you get it.
A chord at the beginning of a second or
subsequent repeat alternative should print
unconditionally, without checking wheth
Paul Scott wrote:
> I don't think it's a bug
> in my understanding of how Lilypond works.
It is definitely a bug. See below.
Also, see the the thread in July 2004 on
this list in which the developers confirmed
that this is a bug. They even seem to have
fixed the bug, but somehow the fix never
ma
Paul Scott wrote:
> Yitz Gale wrote:
>> The Chord Name engraver with chordChanges = #t
>> does not print the chord at the beginning
>> of a repeat alternative if the chord at the
>> end of the previous repeat alternative was
>> the same.
> The way I read th
> The Chord Name engraver with chordChanges = #t
> does not print the chord at the beginning
> of a repeat alternative if the chord at the
> end of the previous repeat alternative was
> the same.
Sorry, my example was a bit thin. It is
hard to see the problem when only the
chords print without a s
Using 2.6.3 on Debian testing, a problem
that was reported here over two years ago
(July 2004) as fixed is still occurring.
The Chord Name engraver with chordChanges = #t
does not print the chord at the beginning
of a repeat alternative if the chord at the
end of the previous repeat alternative wa
