Re: Lilypond and Jazz chords

[David Kastrup]

Kieren MacMillan <address@hidden> writes:

> Hi David,
>
>> Here's my take on how to do this more transparently: first have an
>> engraver that does the basic chord analysis and writes one or several
>> properties with the basic analysis results (like fundamental pitch and
>> scale offsets).  Those properties are made part of text-interface.
>> 
>> Then have several markup commands producing output based on those
>> properties.  Like German chord names, or a markup list with
>> modifications and stuff like that.  And then you can basically create
>> one fixed markup for each chord naming style and assign that to the
>> "text" field of a ChordName.
>> 
>> Also it then becomes easy to put chord names into a TextScript
>
> That all sounds great. If the engraver broke the chord components into
> the smallest possible bits (e.g., root, quality, third stack,
> alterations, bass or inversion), then the NameBuilder (or whatever)
> could format those however one pleased.
>
> However, I’m also concerned that the current input syntax isn’t rich
> enough. For example, one can’t tell Lilypond “at run time" if <c d f
> bf> should be labelled as Bb/C or C7(sus2,sus4). [Note that, at this
> point, I don’t care what anyone’s preference for display of this chord
> is — I’m simply pointing out that I don’t know of a mechanism to force
> Lilypond to label the same set of notes two or more different ways.]

The engraver would convert <c d f bf> into something akin to c c' d' f'
bf' (somewhat opaque example since the first is the root pitch and the
others are the relation to the root note, expressed as intervals from
c').  There would be one or several markups for interpreting the c' d'
f' bf' part of the list.  And likely some exceptions mechanism.

So yes, configurability would still be a hand-wavy thing.  But it would
be quite clear how to assemble one's own solution from scratch and what
building blocks were available for it.

The current situation also offers "from scratch" assembly, but there are
basically no useful building blocks or recognizable mechanisms.

> So we should attack the input mode as well, to support the widest and
> most flexible possible usage.

It's a feature rather than a bug that LilyPond tries to avoid passing
information via anything but the chord pitches: that way you can get
sensible labelling of chords not entered via chordmode.  This is not
complete: some special properties come into play in order to allow for
inversions to be labelled relative to the purported root note rather
than the nominally lowest note.

-- 
David Kastrup