[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Chord changes over repeat alternatives

From: Paul Scott
Subject: Re: Chord changes over repeat alternatives
Date: Sat, 12 Aug 2006 19:07:19 -0700
User-agent: Thunderbird (X11/20060713)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]