Chord pipelines

[David Kastrup]

Hi together,

I am currently contemplating our chord support and it appears rather
badly modularized to me.

Chords are typically generated in \chordmode.  \chordmode generates
music that basically can serve directly in staves for keyboard.

Then we have the ChordNames context.  It uses some internal functions
called via procedures stored in context properties to figure out root
and extensions of such chords.  Then there are several
language/convention dependent chord naming functions building chords.
Which components can be changed in what manner is rather hardwired.

Then we have the Fretboards context which takes a keyboard chord,
associates it with predefined guitar chords, and outputs a translated
fret diagram.  Of course, the same translation would make sense in order
to generate a score for classical guitar players (who tend to be great
at reading scores and soso at actually knowing all those chords by
name).  We don't have _any_ way to wire this chord mapping into score
typesetting, only into fret diagrams.

Now shiver me timbers, I am interested in doing chords for accordions.
Accordions have an x:7 button that is actually x:7^5 and they have a
x:dim button that is actually x:dim7^5.

Now what input would one want for those?  Arguably, x:7 and x:dim since
accordion players generally don't take the fifth regarding those chords.
To make things more confusing, there are accordions with only three
chord button rows: major, minor, and a combined seventh/diminuished
chord row since g:dim7^5 can be employed as c:7^1 (so here, the
accordion players do take the fifth and sacrifice the prime) and is
actually placed in the c chord column.  I digress.

Chord and bass letters/notation tend to be written in several places.
Keyboard chords are placed in a ChordNames context while the
corresponding accordion chords are placed in the bass clef staff (the
three note variants, usually in the octave below c' regardless of
inversions) and annotated with positioning mostly as a TextScript or a
stack of them (when having both a bass button and a chord at the same
time).  Sometimes, a bit more like Lyrics though.

So LilyPond has capabilities for converting chords into chord name
markups, and it has capabilities for putting markups as text scripts or
Lyrics but we cannot combine the chord name recognition with the
delivery as text scripts or other form of outer staff object or into a
Lyric context or a more generic markup-arranging context.

And LilyPond has capabilities for recognizing chords, converting into
the custom shape for instruments like a guitar, but can only produce
fretboards from that custom shape: neither tablature nor note staff.

We don't have chord input naming/shaping conventions similar to notename
languages either, even though there is some low-level machinery doing
that.

And the NoteNames context does not share the multi-language naming
options of the ChordNames context.

As a consequence, extending functionality for other instruments or
creatively using the existing functionality in new ways is not really
feasible.  The various components at work here should be equipped with
reasonably versatile interfaces so that one can plug them into each
other in the existing or other ways.

This is one area where the existing possibilities for customization
(like the chord naming functions in context properties) are of such
limited usefulness that I would consider incompatibility with code using
these hooks an acceptable price to pay for a sane and versatile
redesign.

-- 
David Kastrup