[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lilypond and Jazz chords

From: Brett Duncan
Subject: Re: Lilypond and Jazz chords
Date: Tue, 02 Jun 2009 14:42:29 +1000
User-agent: Thunderbird (Macintosh/20090302)

Carl D. Sorensen wrote:
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.

I agree - determining the chord name based soley on the notes is problematic. What do you call <c d f g>? My first impression is Csus2,4, but I've seen the same chord notated as G7sus4/C and even as Dm7add4/C (no mention of the missing 5th). A lot of the time, the context (or the way the composer/songwriter is thinking about the composition) determines the way the chord is named.

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.

And it doesn't even do that right at times. In my earlier email, I mentioned the chord <d f aes c> that has d as the first note, but the generated chord name is C b6/sus4/sus2.

The only way I think that generating more "intelligent" chord names could be achieved would be to have some way to tag a note in the chord to identify it as the chord root.

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.

True - the current chord mode is unambiguous, and IMO easy to understand. The one aspect of it I don't like occurs when you enter something like c:4 or c:m2 - anyone familiar with chord names like C4 or Cm2 will be expecting a triad with an added 4th or 2nd (or maybe a suspended 4th or 2nd, depending on what convention is being followed). What you actually get is <c e f> and <c d>. Of course, the manual _does_ make it clear what's going on, and you work around it with c:5.4 or c:m5.2, but it doesn't sit well with what is generally understood about chord names, namely that they are based around *triads*. I would prefer to see the notes of the triad remain regardless of the suffix, unless they are specifically removed with ^ (or 'sus' in the case of the 3rd). But I can live with the current syntax.

I'm more interested in getting saner output from ChordNames. When I enter <c e f g> Lilypond generates Csus4add3 as the chord name. Blehh!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]