[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Chord Semantics Patch

From: David Kastrup
Subject: Re: Chord Semantics Patch
Date: Thu, 02 Nov 2017 16:40:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

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?

> 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''> >>

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.

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

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]