Re: Chord changes over repeat alternatives

[Paul Scott]

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