RFC: Forking vs expanding the chord_harte namespace?

[bmcfee]

[started offline in discussion with @ejhumphrey ]

The chord_harte namespace is arguably the most obvious representation for chord data, but we've had to modify it a bit from its original definition. (For instance, we added support for suspended chords.)

It's also currently missing other qualities, eg, 13. Since we've already modified the original namespace, I don't have a problem with adding more options. However, this is somewhat open-ended, and may be misleading down the road.

I see two options here:

1. Continue adding/correcting the existing chord_harte namespace as needed.
2. Fork the namespace. Keep chord_harte as originally defined in its paper, and make a separate namespace chord_??? which includes any expansions or corrections we see fit to include. (Another candidate for correction is mixing of flats and sharps in a note specification; harte allows this, but I think we probably don't want it.)

What do people think about these options? On the one hand, it's good to have clarity and solid reference material for what the namespaces do. On the other hand, if we fork it, I suspect that nobody will ever use the original chord_harte namespace since it's a strict subset of valid chord labels.

[bmcfee]

Unless people object, I'll implement option 2, and call the new default schema chord. The older schema will remain chord_harte, but I'll roll back our modifications to the quality field.

[ejhumphrey]

I don't hate (1); while I see the value of pointing back to a specific reference, I think the distinction from a functional standpoint is unnecessary. We have an opportunity to incorporate knowledge and perspective earned since the initial publication, and there's a certain value in that too.

On Thu, Jul 16, 2015 at 9:41 AM, Brian McFee notifications@github.com wrote:

Unless people object, I'll implement option 2, and call the new default schema chord. The older schema will remain chord_harte, but I'll roll back our modifications to the quality field.

— Reply to this email directly or view it on GitHub https://github.com/marl/jams/issues/48#issuecomment-121958842.

[bmcfee]

I also don't hate (1), but it does no harm to include the original specification as well as our own extended version.

I also took the liberty of fixing the grammar's definition of notes so that you can't have infinite strings of mixed sharps and flats.

[bmcfee]

To be super clear: what we have now is a reference implementation of harte 2005 (called chord_harte), and a new-and-improved version called simply chord. I expect people will use the new and improved one by default.

[urinieto]

I don't really understand chords. So all of this sounds good to me.

On Thu, Jul 16, 2015 at 10:18 AM, Brian McFee notifications@github.com wrote:

To be super clear: what we have now is a reference implementation of harte 2005 (called chord_harte), and a new-and-improved version called simply chord. I expect people will use the new and improved one by default.

— Reply to this email directly or view it on GitHub https://github.com/marl/jams/issues/48#issuecomment-121969927.

[bmcfee]

So, while we're on the topic, here's the new regexp generator: http://nbviewer.ipython.org/gist/bmcfee/88ead8ab4ceb6f92453b

We added qualities (shorthand) "1, 5, sus2, 13" beyond the original spec. Is there anything else missing?

[ejhumphrey]

9's and 11's off the top of my head ... plus intervals can range 1:13, in my experience, because annotators abuse flexible syntax

On Thu, Jul 16, 2015 at 10:36 AM, Brian McFee notifications@github.com wrote:

So, while we're on the topic, here's the new regexp generator: http://nbviewer.ipython.org/gist/bmcfee/88ead8ab4ceb6f92453b

We added qualities (shorthand) "1, 5, sus2, 13" beyond the original spec. Is there anything else missing?

— Reply to this email directly or view it on GitHub https://github.com/marl/jams/issues/48#issuecomment-121975988.

[bmcfee]

Don't we already have 9s?

11s make sense though.

How should/would these be annotated? Examples are helpful for music n00bs like myself.

[bmcfee]

... and because i'm really a total newb, this section seems like a reasonable place to crib from.

[jonforsyth]

I haven't thought about the issue all that much, or recently, but since I've been asked, I'll add my two cents.

It seems to me that a lot of the problems arise from the idea of "shorthand" notation. It can get pretty out of hand. For instance, you have "min7" as a shorthand. But if you have that, should you also have "min9" (which has chord tones 1, b3, 5, 7, 9), "min11" (chord tones 1, b3, 5, 7, 9, 11), and "min13" (chord tones 1, b3, 5, 7, 9, 11,13)? And so on for other chord qualities, and also for the "none" chord quality, since something like C11 is assumed to have a flat 7 (the note Bb) whereas Cmaj11 is assumed to have a major 7 (the note B).

That Wikipedia link illustrates the problem pretty well because it's pretty complete, and also mentions some more obscure chords that aren't taken into account by Harte notation, like the whole "add" syntax. For example, "C7(add11)" or sometimes "C7(11)" means a C dominant 7th chord with an added 11th (and no 9th). There's also quartal chords, slash chords, and polychords. (It might not be worth adding in these other chord types as shorthands, of course).

I don't know what the solution is short of adding in every possible shorthand, or every "common" shorthand, whatever that means. You might be able to accomplish the first more cleanly if you define a shorthand as a chord quality plus an interval (I may not be using the notation correctly here but hopefully it's clear enough):

::= [ ] ::= maj | min | dim | aug | sus But that's still not 100% correct, and doesn't eliminate nonsensical shorthands. A different interval list (i.e. 6, 7 ,9, 11, 13) might help. Part of me thinks we should just forget about naming the chord, and just notate the root, the chord tones, and (optionally) the note in the bass. The shorthand notation is useful when a human is reading a lead sheet, but I'm not sure it makes as much sense for the purposes of annotation. As an example, you could have something like "C:(1,3,5,9)/3", which is a C major triad with an added 9 (D), and the 3 (E) in the bass. This would also get rid of some of the notation abuse where you can notate something as a major triad with no third. I suppose this could make things a little more difficult for the human annotators, but it seems like those are the three pieces of information we need (chord root, chord tones, bass note). Or even just list the chord tones and the bass note (then we don't have to worry about whether the chord tones "A C E G" is an Amin7 or a C6). Now I'm getting carried away... Anyway, just a thought, maybe not a good one. Wait, what was the question again?

[bmcfee]

Part of me thinks we should just forget about naming the chord, and just notate the root, the chord tones, and (optionally) the note in the bass.

Yep! That would make me happy as well, since it would save me from having to learn all this terminology. (Also, it leads to better defined problem formulations, but that's a separate issue.)

Wait, what was the question again?

I suppose I never clearly articulated the question, but the gist of it is:

We have shorthand strings for the different flavors of triad, seventh chords, etc. The 9th, 11th, and 13th chords seem relatively impoverished in their current state (compared to the 7ths) and I was wondering if we should flesh them out, eg, using some variation of the "long symbol" notations in the wikipedia article. If so, where do we draw the line?

[bmcfee]

Okay, let's try to simplify the question. Does it make sense to do something like:

<shorthand> ::= maj | min | dim | aug | 
                1 | 5 | sus4 | sus2 |
                maj6 | min6 | 
                maj7 | min7 | 7 | dim7 | hdim7 | minmaj7 |
                maj9 | min9 | 9 | dim9 | hdim9 | minmaj9 |
                maj11 | min11 | 11 | dim11 | hdim11 | minmaj11 | 
                maj13 | min13 | 13 | dim13 | hdim13 | minmaj13

?

Maybe this set isn't exactly correct, but the alternative is to rely on the degree list notation for added notes in extended chords. This is basically what's done in Harte, but that's apparently inconsistent with some data that @ejhumphrey came across?

[jonforsyth]

If I'm understanding correctly, the shorthand is purely for convenience, in which case you really just need the most common shorthands. If so, I'd say your list in the previous post is good, except that as far as 9ths, 11ths, and 13ths go, you probably just need 9, 11, 13, maj9, maj11, maj13, min9, min11, and min13. You also might want to add "aug7".

[bmcfee]

If I'm understanding correctly, the shorthand is purely for convenience, in which case you really just need the most common shorthands.

Yes, in the sense that we can always spell out a chord explicitly with included/suppressed degrees, so there's always a way to describe any set of pitch classes (within reason). How do we determine "common" though?

you probably just need 9, 11, 13, maj9, maj11, maj13, min9, min11, and min13.

Ok, so basically what Harte does for 9ths, but expanded to 11th and 13th, rather than expanding up from what Harte does for 7ths. That's fine, as long as we're consistent about it. Making the cut at the octave level seems clear enough to me.

You also might want to add "aug7".

sure.

EDIT: The proposed shorthand set is now

<shorthand> ::= maj | min | dim | aug |
                1 | 5 | sus4 | sus2 |
                maj6 | min6 |
                maj7 | min7 | 7 | dim7 | hdim7 | aug7 | minmaj7 |
                9 | maj9 | min9 |
                11 | maj11 | min11 |
                13 | maj13 | min13

does this seem okay by everyone?

[jonforsyth]

To be honest, I'm not sure how to determine "common", my suggestions were just guesses about what would be most useful.

[bmcfee]

Ok. Well I think the "common" question goes away if we decide that extended chords only get dominant/major/minor, which is a consistent generalization of Harte's grammar.

[jonforsyth]

That seems reasonable.