Re: Request for Comment - Chordname strategy

[Jan Nieuwenhuizen]

<address@hidden> writes:

> I've been quietly mulling over how to undertake a rewrite for the
> chord name generation for a while.

That's very good news.

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

Yes.  As you have noticed, the chords code is in desperate need of a
rewrite.  Some background:

We have had many requests for chord notation that made me decide to
implement chords for Lily, although I was/am not familiar with the
usage of chord name notation.

The biggest problem with chord names, as I see it, is the fact that
you won't find any two people on this planet that agree on all chord
names for any given piece that contains more than five non-trivial
chords (can you read a hint of frustration in that?)

After I decided to implement chord names, I tried to get `the rules'
for chord names, but it seemed that we could not get any consensus on
the mailing list, even about trivial chords.  So, I decided that the
notation (naming) of chords should be decoupled from the chord entry,
and fully customizable to the user's wishes.  This would guarantee
that you'd only have to enter a certain piece of chord music once: it
would seem a bit silly to me if you'd have to enter chord names for
all different styles by hand, like you do with lyrics for different
languages, eg.  That's how I came up with the symbolic-name -> pitches
-> chord-name scheme.  Note that you can automatically produce German
chord names, that uses some different names for the tonic, for
example.

I bought a booklet on chords (Banter) that uses a remarkably logical
strategy for naming chords, and decided to only implement the Banter
names as an example.  The idea was that the people who actually needed
a specific naming scheme, would (be able to) implement different
backends.  This turned out to be a bit of a mistake.  Writing a
backend is a lot hairier than I hoped, so I took a shot at American
and Jazz backends (with the help of Amelie Zapf).

> I am hard pressed to come up with an approach that will
> algorithmically convert a list of pitches to a chord representation
> consistently.

Do you mean to say that you think it can't be done (or is almost
impossible to do)?  You realize that we normally don't convert just a
list of pitches to a chord name.  That's what I tried originally,
because I was told it could be done, but the code got it wrong far too
often.  Currently, the Tonic is marked, as is any Inversion or Base
note.  Maybe we would 'just' need to add more markers, notably for
modifiers or additions?  In absence of tonic and inversion, the some
guess work is done, but that's just a bonus.

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

You're losing me here.  Converting a chord name to pitches is not too
difficult, the real challenge is pitches to chord name.

> 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

I agree.

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

I can imagine it would be easier, but I'm a bit hesitant towards yet
another typesetting language.  Currently we have two: plain embedded
TeX and scheme markup, and both are not very elegant solutions.

> The major problem in the
> current implementation is figuring out what part of a chord is chord
> modifier, and which part alteration.

Ok.  So, can't this be fixed by storing this information when the
chord is parsed?
 
> 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.

Indeed.

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

Yes, that's one of the things I noticed.

> 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).
 
Yes.  I was thinking of an implementation that is more fine-grained,
and use several preferences to combine to styles such as American or
Jazz.  That would allow users to create almost their own style without
huge exception lists.

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

That's sounds nice: simple is good.  Can it do things like
automagically use tonic name H for B-natural?

> The price: inability to use <> notation. The advantage: significant
> flexibility for authors in how chords are notated.

I see no problems with dropping support for <> notation per se.

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

That depends very much on what road you take.  You can use a
special/magic chord/tonic name ('r' from rest comes to mind) or set a
property for the chord name engraver, telling it to ignore chord
events and set a string instead.

To summarize: If possible, I would really like to have the entry
decoupled from the actual notation, much like it is now, maybe by
adding some hinting.  However, the current chord code is broken for
anything but the most trival chords, so I would be already quite
pleased with chord code that just works.


Greetings,
Jan.

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org