Re: Chords in LilyPond

[David Kastrup]

Charles Winston <address@hidden> writes:

> Hi David,
>
>>> Hi all,
>>> 
>>> There have been some great discussions about new chord functionality you’d 
>>> like to see in LilyPond. The first step is defining the internal 
>>> representation. From there, I think all these issues can be much more 
>>> easily solved. We have the EventChord structure, which contains an 
>>> ‘articulations and ‘elements entry. The ‘elements entry contains some 
>>> information about the root and inversion, but otherwise it is a list of 
>>> NoteEvents to be iterated over. My plan is to add a ‘semantics entry whose 
>>> elements will be semantic aspects of the chord:
>>> 
>>>     -root
>>>     -quality of the third (minor, major, none)
>>>     -quality of the fifth (diminished, perfect, augmented, none)
>>>     -extensions (7, 9, 11, etc.)
>>>                     my plan for this is to have a list of extensions, each 
>>> extension associated with a bool indicating its presence in the chord,      
>>>              and associated with an alteration.
>>>     -added notes (6, 9, etc.)
>>>                     implemented similarly to extensions above
>>>     -suspensions (sus4, sus2, etc.)
>>>     -added bass note
>>>     -inversions
>>> 
>>> Let me know what more should be added to this list.
>> 
>> Any reason this information should not be stored in the NoteEvent events
>> actually carrying the pitch information like it is done right now?
>
> Storing this information in the NoteEvents is clunky in my opinion,
> and defeats the purpose of this project—the contexts that need the
> semantic information shouldn’t need note information, and the contexts
> that need note information don’t need semantic information.

So you think that LilyPond should not be able to identify chords, only
reproduce them as entered?

>> It sounds like you are planning to add a completely different and
>> orthogonal mechanism for specifying chords
>
> Yes, I am planning on adding a completely new mechanism for specifying
> chords which LilyPond currently doesn’t support. This thread has
> talked about the numerous benefits of an internal representation which
> understands the semantics of a chord beyond its notes.

s/beyond/instead/ if I understand correctly.

>> it is not clear to me what the results would or should be when the
>> respective information differs.
>
> I’m not exactly sure what you mean by the respective information
> differing? If you mean the note information differing from the
> semantic information, the goal is that that will not happen.

\new ChordNames \fixed c' { <c e g> <f a c'> <g b d'> <c e g> }

currently produces the "correct" result.  You would want it to fail
since the notes have not been entered in chord mode?

> Even if it does, it should not create too much trouble, because
> contexts will not use both forms of information, and it would be the
> user’s mistake in causing the information to differ.

-- 
David Kastrup