Chord Semantics Review

[Charles Winston]

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