> I’m participating in the Google Summer of Code working on improving LilyPond’s internal representation of chords.
Thanks for the help! It is great to see the advancement of Lilypond.
> The goal here is to create a data structure that will represent a chord’s semantics beyond just a list of notes in the chord.
I'd like to talk about a few different kinds of semantics to tackle.
1) The analysis of note patterns is one kind, which is what we currently have.
2) Construction semantics (additions, subtractions, etc) I would argue is not quite musical semantics. It is both what our internal representation uses, and consistent with the direction you are proposing.
3) Musical semantics could include functional anaysis of chord quality (maj/min/etc) or harmonic function (dominant/tonic/subdominant). We support only the quality interpretation of musical semantics. An argument can be made for adding a dimension for harmonic function.
But we only support chord quality insofar as we can map note sets to chord qualities and back. The quality is not in the picture when it comes time to determine the layout, only the note set.
4) Visual semantics would be realated to how to express or format the chord symbols, which otherwise are the same in terms of note sets and musical semantics.
My first comment is about how to interpret all this the "construction" semantic information.
In general, I would hope that people only use alterations if the changes don't coincide with a pre-existing chord. You don't say Cmaj(b3), you'd say Cmin. Similarly, you don't say Cmaj(add b7), you'd say C7.
However, these dimensions of chord modificiation (addition, alteration, subtraction) are used pretty willy-nilly in lots of combinations IRL, and we should probably support everything that make mathematical sense, if not semantic musical sense.
In particular, showing both C+7 and C7#5 should be supported, even though they are identical in terms of both notes and harmonic content.
This case could be solved just treating the semantics as primary (if they are specified), rather than the note set. Instead of mapping the layout to sets of notes, we could map the layout to the semantic representation.
One way to interpret this in a data structure analogy is that we are constructing a mult-dimensional array with the dimensions being chord specificiations (quality, extensions, additions, etc.), and any distinct array value counts as a possibly distinct chord, for which we can define a layout. This allows us to distinguishing between what are otherwise the same note set.
I am under the impression that this is coherent with the approach you are taking, but I just wanted to try to clarify the problems being solved and the benefit of the approach.
Next, I want to make an argument for adding a visual semantics dimension to the chord definition.
One uses case iis notating the C- C-/B C-/Bb C-/A sequence as C- /B /Bb /A.
Another case is writing expanded chord the first (or last) time, but an abbreviated version of the chord the rest of the time. For example, C-9 (maj 7), but then on repeats just write C-. Or C7sus4 the first time and then Csus the rest.
These are examples of two different layouts showing the same chord. In this case, the chords have both the same notes and the same musical semantics. Only the visual semantics differ.
So, we need a way to input and handle visual semantics as another possible dimension of the chord definition.
This value could be an identifier that serves to distinguish between chords that are otherwise considered identical according to the other chord dimensions. An example of a possible input syntax would be
C1:m|no-root|/B
Some of the other "give me what I type" requests could work this way
C1:|aug7addb9|
Where we give no semantic info, but only specify an identifier that they can then map to a layout.
Or, perhaps be able to map an identifier to another chord definition.
|aug7addb9| = +7.9-
On the topic of midi, some of the above cases demonstrate having the same notes produced by different semantic and visual representations.
But I'd also like to suggest, like with the fretboard chords voicings, the ability to map a given chord to a different set of notes. The concept is to mimic more closely what an improviser actually does with chords. So, for example if you belive Mark Levine, a C major chord might be played something like <b d e a>.
So, we'd want to have a mappings of <c e g> => C major => <b d e a> of some kind.
And then have the midi output use the mapped versions.
> Here is a rough list of semantic information I believe should be included in the data structure:
> root note
> quality (major, minor, augmented, diminished)
> extension (7, 9, 11, 13, etc.)
> added notes (6, 9, etc.)
> suspensions (sus4, sus2, etc.)
> alterations (flat-5, sharp-9, etc.)
> omitted notes
> added bass note
> inversions
> Some things that should be thought about:
> Is the 7 an extension? Or included in the quality the chord? Or maybe something else?
I'd say that in order to support common practice harmony, the list of qualities would need to include dominant.
This implies that the quality should be extended to include the flavors of 7th chords as well. The half diminished chord is a distinct quality.
As things get more esoteric, for example, a minor chord with major 7th is common, but is it really a different quality?
Again, I think we'd want to design for covering the mathematical space (let people define their own qualities).