Charles Winston <chazwi...@gmail.com> 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 _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user