Having said that, there's one part of Lilypond that I'm not so enamoured with. The chords mode. Compared to the rest of the program, it needs significant work. (But it is just my opinion - feel free to disagree!)
Here's a picture to illustrate some of the things I have issues with.
What is shown here is a series of chords, underneath them what was typed into Lilypond to produce the chords, and above them what Lilypond produces as the names of the chords.
The first line of chords concerns the 'sus' modifier. This modifier does do what it is supposed to - it removes the third. But for some reason, the name of the chord does not include the 'sus' part unless the 2nd or 4th is part of the chord. The third chord along illustrates how Lilypond cuts out the 5th when the 4th is specified before the 'sus' modifier, but the resulting name is weird.
The first two chords of the second line show two different ways of entering a "half-diminished" chord; the first way seems the more logical, as the chord is more properly a minor 7th with a lowered 5th. (Some people I worked with prefer to see 'Cm7b5' instead of the slashed circle.)
The next two chords show that there is no difference in entering 'maj7' and just 'maj' - both result in the triangle. Some prefer to see a 7 after the triangle, but the triangle by itself is uambiguous. What bothers me is what happens with the major 9th (last chord of the second row) - why is there a slash? (I always understood slash notation to be a indication of the bass note to be played under the chord.)
The third line shows two different ways to enter a minor with the major 7th. The first way is the logical way (you enter the minor and add the raised 7th), but as before, you don't get the 7 after the triangle. Again, some will prefer to see something like 'Cm(maj7)'.
The last row shows an inconsistency in the naming of the chords. C9 and C11 appear as described in Lilypond's documentation. C13 omits the 11ths but includes the 9th - when I ask other musicians what they think makes up a 13th, I get various answers. The 11th is almost always left out, but the 9th is often left out as well, and sometimes so is the 7th. (Isn't that a 'C add 13'?)
The name of the c:13 chord comes out as C9/add13 (why?), but if you add the 11th, as in the last chord, that chord gets named C13 - what the...??
Now, I know all too well that it's just not possible to get a set of naming conventions for chords that is going to satisfy everyone. But I think it ought to be possible to develop a set of naming conventions that could be adapted into Lilypond that would be reasonably consistent in itself, having a better correspondence between what gets entered and what chord names appear on the output (e.g. the chord entered as 'c:13' has the name 'C13' on the output), and which is sufficiently succinct for ease of reading as you play (e.g. 'Csus13' rather than 'C7 add9,13 no 3rd').
2 comments:
I don't know much about chord naming conventions, but I know a fair amount about the chord naming programming in Lilypond.
As I've reviewed the chord naming code, it appears that there are at least three different "standards" for naming chords, along with a number of variations.
It's certainly possible to define your own chord naming convention, and it's easily implemented in Lilypond. However, to get it added to the distribution, it probably needs an authoritative reference.
The input notation is slightly different. I believe that the input notation is unambiguous (at least it should be), but it may not conform to the naming standard. It's possible that the chordmode parser could be changed to recognize the current output mode. However, this could be problematic. Suppose that I have a perfectly working piece of music, for somebody who likes the American Jazz output. Someone else would like to have Ignatzek chord names. So I change to Ignatzek. Now, all of a sudden, I have to change all of the chord entry to conform to Ignatzek. That's why I think it best to have one input syntax, even if it doesn't match all output syntaxes.
Thanks for your work in identifying the issues. If you'd like to work further on this, I'd be happy to see if I could provide a hand.
Thanks for your input Carl.
I don't see any real issues with the input notation - as you say, it is unambiguous, and I find it quite easy to understand; the only thing I would like to see changed about it is how it handles the 2nd and 4th extensions (that is, c:2, c:4) - currently the "top" of the chord stops at the number after the colon - I think it would be better if the basic triad was always part of the chord unless the 3rd or 5th are specifically taken out.
I agree with you about having a single input syntax - more than one would just be a recipe for confusion.
Shortly after I posted this blog entry, I created my own set of chord name exceptions to get the names I wanted, since I wasn't happy with the Ignatzek names. I now have this in a single file (actually I have two versions, one with the usual jazz symbols, and a slightly more verbose form) and just use \include to use the file. I'd be happy to give the file to anyone who wants it.
Post a Comment