Request for Comment - Chordname strategy

[rerdavies]

I've been quietly mulling over how to undertake a rewrite for the chord name
generation for a while. Along the way I've run into a number of nightmare
chords (C:5+.5-.9+.9-, for example), and a number of chord-writing
conventions that really challenge the current approach being taken for
chords in lily

There are definite common threads for chord naming. The grammar for
converting from a chord representation to pitches is relatively
straightforward. But I am hard pressed to come up with an approach that will
algorithmically convert a list of pitches to a chord representation
consistently. The current code just barely gets by with chords of low degree
(up to the 7th out of the box, mostly, up to the 9th after special-casing
with overrides), and fails spectacularly with 11ths and 13ths.

After having mostly completed a rewrite of the ChordName to pitch code, it
became apparent to me that the opposite problem (converting a chord
representation to pitches) is much easier. Perhaps a regrouping might be in
order.

So I'd like to put forward the following idea for discussion.

The current implementation converts chord names to pitches and then converts
pitches to chord representations on the page. This two step conversion makes
it easier to support an alternate method of chord entry, which is to enter
pitches using note names (e.g.  <c d e bf d fs>). Although this is arguably
a great feature for novices, it is dubiously useful for people who use
chords a lot -- jazz charts (my personal motivation for these fixes) being
an example of where it would be absolutely brutal to use <> chord notation
throughout.

Implementation of chord representations would be much easier if we were to
consider chord names within a .ly file to be a typsetting language for
chords than if we were to consider them to be (as they currently are) a
convenient way to specify pitches in a chord. The major problem in the
current implementation is figuring out what part of a chord is chord
modifier, and which part alteration. For example, should c:5+.7+ produce
Cmaj7(5+) or Caug(maj7). Lower chord degrees are dealt with in a
straightforward manner in the current implementation: but about 50% of all
possible combinations are caught by exceptions in lookup tables. When we get
to higher degree 11th and 13th chords, the exception tables are no longer
manageable, and the problem of algorithmically separating modifiers and
alterations is daunting.

Furthermore, choices of when to use "no" and when to use "add", for example,
are highly idiosyncratic, and are probably almost a case-by-case personal
preference. Cadd9 for sure, c no 5 for sure, C no 3 special case, C 13 no 11
or C 9 add13 or C 9 add 6? The current strategy of ignore "No"s for jazz
chords is really not right. If someone asked for it, they should get it,
whether we think it's a good idea or not (which it probably is).

A good example of how this approach might work is Cubase Score. In Cubase
Score, chords are specfied using the following pieces: root, modifier,
alterations, base.  e.g.    "Cs"  "m7"  "-5" "/B". This produces (depending
on various style options)   C#m7(5b). The Cubase chord entry system is so
simple and flexible it brings tears to my eyes.

This idea is easy to graft onto the current lilypond grammar. Chord
representations would be generated in a straightforward manner from the
chord name tokens in the .ly file, without going through the intermediate
pitch conversion.

The ^ character could be used to separate root and modifier portions of a
chord. (Either that or allow brackets or some other grammatic construct).

e.g.    C:m7^5-   produces Cm7(5-)   ((5-) is superscripted in american and
banter).
          C:^5-.7    produces banter style  C  (5-/7)

It's easy to convert C:aug^13   to C+ (13), and C13^5+ to C13(5+), from the
ly parser tree, but seriously challenging to convert to either from a list
of pitches. On the other hand, it's trivial to convert either of these  to a
list of pitches for proofing (MIDI or staff) purposes.

Similarly, C:13- represents a serious conversion challenge. C:7^13- (yeilds
C7(b13)) or C:11^13- (giving C11(b13) ) are both easy.

I forsee making grammar changes so that things like the following could be
used to specify fairly precise chord representations.

C:^(6/9/no7)   (banter style notation.
c:6.9   (american notation).
       (yeah yeah, I know -- the one problematic case in pitch production --
although it's easily solved).

C:^sus4 or C:sus4

c:^add9

c:m^13.11+   (american style).

My short list of basic operators might include:

()  - Literal brackets in the output.
^  - superscript.
/    - literal slash.
+-   - Configurable: 13b 11#,   b13 #11, 13- 5+ etc.
hdim/dim/aug/sus/maj/min : configurable.
add/no   - configurable "No" "no" &c. "add" "+" (to give +9# for example)
|   - stack. jazz style, like this:
                  13-
          CM7
                  5-

The price: inability to use <> notation. The advantage: significant
flexibility for authors in how chords are notated. As an added bonus we
might get figured base notations for free (c:6|9 assuming nobody wants to
midi preview them).

On the same topic, but in a much easier vein, I would very much like to add
support for "N.C"/"No Chord" to the chord engraver, although I'm not sure
what the easiest way to do this is. Something to do with fielding text
events? Or fielding rest requests? Either would do. My preference would be
to allow arbitrary strings in the chord line (e.g.   "No chord."1). The
ability to add notations like "Modal Em" or "Modal F Locrian #2 Free Improv"
(solo for 32 bars) would be nice (used in several Miles Davis arrangements).
Also nice, would be the ability to place brackets around optional chords in
a turnaround. Advice on strategies for doing this would be appreciated.

e.g.

     |   F       |   (Dm      G7b9)    :|