Yitz Gale wrote:
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.
I still don't think so. I have been using LilyPond for at least 4 years
and have produced many lead sheets and music with chord names. The
behavior described in the documentation gets the job done even if you
disagree with how it should work. I believe you are expecting more than
the developers had in mind. The goal of this program is to engrave
music not interpret it.
Also, see the the thread in July 2004 on
this list in which the developers confirmed
that this is a bug.
Eric Sandberg agreed to list it as a bug. He said he won't be available
for a while. I'll bet he admits it's not a bug when this is all over.
The behavior described by the original poster is exactly the behavior I
expect from LilyPond for both chords and notes. LilyPond is not Finale
or anything else. It pays no attention to endings or repeat as far as
notes or chordnames. The only thing LilyPond knows is bar after bar.
They even seem to have
fixed the bug, but somehow the fix never
made it into CVS.
Han-Wen only says it didn't get committed to the bug list. There is no
mention of a fix in that thread.
Your example doesn't use the
chordChanges = #t feature
It does use the feature. I wrote chords
for all of the notes, and Lilypond decides
which ones to print. Only chords changes are
to be printed.
That works fine throughout, except at the
beginning of the second ending. There Lilypond
skips the chord even though it is a change.
That is the bug.
My example is very short and contrived, of course.
In real music there could be hundreds of places
where chords are correctly skipped.
Your example works correctly. If chordChanges is false (default) the
F's occur 3 times just as you say. If chordChanges is true the 2nd and
3rd F's are omitted because they are the same chord. Again as much as
you might like the endings have nothing to do with it.
Did you try chordChanges = #f ?
I believe it will make your example do exactly
what you want.
No, it is wrong. It prints chords all over the
place that I do not want it to print. With
chordChanges = ##t everything is correct,
except in the case where the bug occurs.
If you can carefully describe what you want different than the current
behavior I can help you get it.
Indeed I just tried it and it does exactly what
you said you wanted it
to. To be exact the following works:
No, your example does not do what I want.
I want Lilypond only to print chord changes.
Then why did you put 3 F's in a row. F to F is not a change.
Your example prints chords even when they
are not changes.
Only when I set chordChanges to false.
Lilypond's chordChanges feature works great
for that.
I agree.
Except that I am reminding
the Lilypond team that there is still a bug
in the case I pointed out.
As pointed out above Eric agreed to put it on the bug list but he's not
even the bugmeister any more. We'll see what Graham or someone else has
to say here.
HTH,
Paul
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond