Re: Chord Semantics Patch

[Charles Winston]

> On Nov 2, 2017, at 11:40 AM, David Kastrup <address@hidden> wrote:
> 
> Charles Winston <address@hidden> writes:
> 
>> Hi developers,
>> 
>> I posted a new patch on Reitveld that captures the semantics entered
>> in chordmode in order to produce more accurate chord names. The way it
>> works now, the input: \chords { c:m7.1 ees } will produce identical
>> chord names: Eb. Though with my patch, c:m7.1 produces the name Cm7
>> omit root, as it should.
> 
> You mean c:m7^1 I presume?

Yes of course. My bad.

> 
>> The patch captures all the relevant information entered in chordmode:
>> root, extension, modifier, alterations, additions, removals, bass,
>> inversion. It saves this information as a ChordSemanticsEvent, part of
>> the elements of EventChord. This event is iterated and passed to the
>> chord_name_engraver, which uses a new naming function to produce chord
>> names based on the semantics list.
>> 
>> Let me know what you think,
> 
> What does the chord name engraver do without such an event?
> 
> With this Scheme we should likely have an engraver that will listen to
> note names and, upon hearing the first of them, create a
> ChordSemanticsEvent (which means that the ChordSemanticsEvent should
> likely be placed _first_ in a chord in order to override that
> generation), then update it as note events arrive so that by the time
> process-music is called, the ChordSemanticsEvent is complete.
> 
> That doesn't quite help with things like
> 
> \chordmode << c <f''> >>

When there is no ChordSemanticsEvent (i.e. when chords are entered in node mode 
and not in chord mode) the chord name engraver listens to the note events and 
names the chords with the old chord name function, just like every chord was 
named before.

I’m not exactly familiar with the formulation "\chordmode << c <f''> >>” — it 
seems like this is mixing chord and note mode in a way that I do not 
understand. Is this legal LilyPond syntax?

> 
> However, it's not clear that a single chordname should be generated from
> that.  Accordions use things like << c e:m >> in order to generate
> c:maj7, or even << <c> e:m >> (and piano chords above the staff should
> combine this to Cmaj7 while the accordion chord notation typeset in the
> place of an articulation should be C+em) .  But it still would be
> important to know just what notes are accounted for by a
> ChordSemanticsEvent and which not.  Though, well, we can likely count
> them off.  We just collect all events in order, and a
> ChordSemanticsEvent will state (at the time process-music is called if
> it has been generated by an engraver rather than input) how many notes
> it feels responsible for.

The notes the ChordSemanticsEvent accounts for are the root, bass, and any 
additions or removals. Which manifest themselves as semantics.

> 
> Well, it may be workable.  At least the current way of putting inversion
> and root information on chords is just cryptic.
> 
> -- 
> David Kastrup