Re: Chords in LilyPond

[Carl Sorensen]

On 5/28/17 5:53 PM, "Thomas Morley" <address@hidden> wrote:

>
>
>Though, why adding a Œsemantics entry to the EventChord?
>I'd suggest to write such an interpreter as a procedure which works on
>the pitchlist ignatzek-chord-names currently has to work with
>(including bass/inversion-info). Then write a printing-function which
>works on the result of the interpreter.
>Both public in guile, so that users can write different interpreters
>and printing-functions as they like.


There are three different problems in the Chords construct.

1) How to input chords.  We currently have two modes -- notemode and
chordmode.  Notemode has no semantics.  Chordmode has semantics, but
currently the semantics get largely tossed away (except for root, bass,
inversion, IIRC).

2) How to determine a chord name.  For this, we currently have
ignatzek-chord-names which interprets the pitches plus root, bass,
inversion into a chord name.

3) How to display a chord name. This is currently mixed up with the
determination of a chord name in ignatzek-chord-names.

Charles's project is not to solve all three of these.  In fact, his
project is not to completely solve any one of them.  Rather, his problem
is to determine how best to save the semantics, so that assuming the
semantics are properly entered in chordmode (probably including some
extensions to the current chordmode, or maybe even a start from scratch
rewrite, but that's out of scope for this project), the semantics will be
kept as part of the chord, and thus be available for the
chord_name_engraver to use when generating a chord name.

When Charles is done, I hope that we will have a good internal
representation for both the notes and the semantics.  The user will have
the ability to define the semantics (at first, maybe only with Scheme, but
eventually through good input).  And those semantics will lead to the
desired output.

Right now, we don't have control of the semantics; they're inferred from
the pitches.  And that causes problems.

Of course, we'll need to get good display routines (printing functions).
And we'll need to get good input routines (for both chordmode and note
mode).  And we'll need to get good infer-semantics-from-pitches routines
(which Harm calls interpreters, I believe).  But if each of these can be
separated from the others (which I hope Charles's project will do by
capturing semantics properly in the EventChord structure), then I believe
it will be easier to tackle all of the problems.

Thanks,

Carl