Hi developers, I’ve just uploaded a patch for review as a part of my Google Summer of Code project to improve the internal representation of chords. What I’m aiming to do here is eliminate the ambiguity that comes from naming chords simply based off the notes. Currently, the information input in chord mode is lost as soon as the EventChord is created. This can cause problems with naming when different chords have the same notes. For example, if I type
\chords {c:m7^1} Then the engraver names the chord Eb. But we really want it to call it Cm7 omit root. So what I’ve done is maintained the information from chord mode in a new music event ChordSemanticsEvent, which is a member of the elements property of EventChord. This translates to a chord-semantics-event stream event to be accepted by the engraver. The engraver listens for this event and if it encounters it, calls a new chord name function to create a markup based on the semantics. I’ve got most the basic functionality working for this new procedure, but some things that still need to be tackled are: dealing with the special case major 7 modifier (right now it outputs E∆7 instead of just E∆), treating sis differently from other modifiers (it should be super scripted), and dealing with removals in an appropriate way. I’ve also included a chord-step property to NoteEvents. This chord-step property says the interval a note is from the root, which contains a step number and quality. This could be used for more complex chord naming, possibly for chords not based on triads, like quartal chords. After getting the new chord name procedure right, I believe the next step is to expand chord name exceptions to work with this new chord naming structure. I would love for this patch to be reviewed. Here is the link https://codereview.appspot.com/321250043 <https://codereview.appspot.com/321250043> Thanks, Charles Winston _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel