Re: Lilypond and Jazz chords

[Carl D. Sorensen]

On 6/1/09 12:50 PM, "Grammostola Rosea" <address@hidden> wrote:

> Tim McNamara wrote:
>> 
>> On Jun 1, 2009, at 4:13 AM, Tim Rowe wrote:
>> 
>>> 2009/6/1 Carl D. Sorensen <address@hidden>:
>>> 
>>>> You are welcome to pursue this, if you are interested in it.  It is
>>>> not my
>>>> interest.
>>> 
>>> I think it shows the impossibility of what you are trying to achieve,
>>> at least in the completely general case, although pushing the
>>> boundaries closer to that general case is valuable of course. Beyond
>>> trivial cases, a combination of notes does not have /a/ name, it has
>>> many names depending on the musical context.  For jazz chords, the
>>> chord notes and the chord names really need to be separated (perhaps
>>> an optional name following the notes) unless the software can
>>> understand the musical context better than a lot of musicians. Or just
>>> stick with chord mode.
>> 
>> Particularly when entering the notes and the root is not the chord
>> name.  For example, a chord I saw in a Pat Martino chart would have
>> included:
>> 
>> <d des fes aes>
>> 
>> which was written as Dbmin/D.  I have no idea how one would make
>> LilyPond properly interpret slash chords or compound chords from note
>> entries.  

As far as I can see, there is very little hope for LilyPond making the right
decision about this chord entered in note mode.  The first note is not the
root of the chord, so it would require substantial computation time to try
to identify the chord properly (and there's no guarantee that the proper
chord identification is unique, based upon just the set of notes).  I'm not
even proposing to *try* to attack this problem.

As far as my current plan goes, this chord would be identified as a D chord
of some type, as is the current practice in LilyPond.  If the root and
inversion have not been identified (which they will not be when chords are
entered in note mode), then the first note in the chord is identified as the
root, which gives weird chord names.


>> Rendering chords written as chord names (des2:m5/d) would of
>> course be simpler.

Yes, and that functionality is not currently as strong as we'd like it to
be, I think.  That's what I'm proposing to rework, when I get the chance.

>> 
> I agree with this.
> 
> Couldn't there be an 'automatic chord mode' and an 'mode which just
> display the chord names', not the notes?
> 

What do you mean by 'automatic chord mode', and  'mode which just displays
the chord names'?

We currently have a context which just displays the chord names.  It's
called ChordNames.

We *don't* have a mode which just *accepts* chord names.  We have a mode
(chord mode) that accepts a root, a modifier, a maximum chord step, and can
add, remove, and modify chord steps, including moving a pitch to the bass or
adding a pitch to the bass.  This mode does not use "chord names" per se,
because chord names tend to be ambiguous (all one needs to do is look at the
variety of names for a given chord as defined by a set of pitches to see
this).  Parsers tend not to deal well with ambiguities, so what we have is a
completely non-ambiguous input format.  Someone who understands the
chordmode input format can look at a chordmode expression and determine
exactly what pitches are intended to be included in the chord.

A chordnamemode *input* mode has been proposed a couple of times.  This mode
would take only a root (and optionally, a slash or alternate bass note), and
everything else about the chord would be in the form of a markup.  For
american jazz chords, this functionality seems to be feasible (but it
couldn't handle the german practice of making minor chords have a lower case
root name, instead of an upper case root name for a major chord).  But I do
not have the expertise to implement such a mode, and I'm not really
interested in spending my time to develop such a mode.  For somebody who is
familiar with the parser, it may not be a huge deal to implement such an
input mode.   

If we had such a mode, we could add properties to a ChordEvent, I think we
could add the necessary properties to store the chord name information that
was generated by the input.  And the ChordNames context could be modified to
display those (except that I'm not sure how slash notes would be handled;
but I would guess it's possible to do so).

I guess that the bottom line to this ongoing request for a chord name
*input* mode may be able to be implemented, but it will likely take somebody
who is interested in it deciding to put in the time to make it happen, like
Marc has done with tablature.  Discussions about how it might work, what the
input syntax should be, etc. can be held, but they will remain just
interesting reference material until somebody decides to do something about
it.

Thanks,

Carl