lilypond-user
[Top][All Lists]
Advanced

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

Re: Chords in LilyPond


From: Charles Winston
Subject: Re: Chords in LilyPond
Date: Sun, 28 May 2017 11:52:13 -0400

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.

> 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.

> 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. 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.

Thanks,
Charles


reply via email to

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