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 _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
