Chord extensions in Songsmith: a discussion thread for theory nerds RRS feed

  • General discussion

  • I'm going to pose a fun question for any music theory nerds like myself who are also interested in Songsmith, on the topic of how Songsmith chooses extended chords (e.g. maj7, min7, etc.)

    First a little background about how Songsmith works (much more info on our research page). Songsmith has a model - learned from actual song data - that maps melodies to sensible chords, and a model - also learned from actual song data - of sensible chord transitions.  So when you give Songsmith a melody, it picks a sensible chord sequence, which of course you can adjust with the tools in the Songsmith UI.  But there's not enough training data in the universe to learn those models for extended chords (7ths, 6ths, etc.), only the basic triads (maj/min/aug/dim) (and we called "sus" a basic triad for convenience).  But of course you still want to mix it up with some chord extensions, so once in a while you can get C7, Dmin7, G13, etc.

    First fun question for theory nerds who also write code: given that we're using machine learning to generate the chord sequence, but don't have enough training data to do extended chords, what would you do to get extended chords in the mix? :)

    Now I'll tell you what Songsmith does.  In all the time I spent working on Songsmith, the most fun 1-hour project was file you'll find in the Songsmith installation directory called "substitutions.csv", which basically tells you everything that's in this post, in the comments at the top of the file. 

    When the user turns the "jazz factor" slider up past some threshold (which isn't that high, maybe halfway), then *after* Songsmith picks a sequence of basic chords for a melody, it turns to this table, which was hand-coded in excel, to say "which chords are most likely to have extensions, and what should those extensions be?".

    Assume everything is in the key of C; the whole table gets transposed as appropriate to the key of the current song.

    The two columns on the left (columns A and B, if you're looking at the file in Excel) indicate a chord (anything that doesn't appear here was too rare to bother with).  Then you can ignore the next three columns.  The "substitution multiplier" column (column F) defaults to 1.0, and says "how likely is Songsmith to extend this chord at all?".  So for example, the "0.65" by "C Major" says "The major I is a little less likely than other chords to ever get extended", and the 1.2 next to "E Major" says "the major III (or major V if we're in A minor) is a little more likely than other chords to ever get extended".   This value is multiplied by a value representing the current position of the "jazz factor" slider, so C is always less likely to get extended than E, but they both get extended more often as the slider moves to the right.

    Then you'll see a bunch of columns corresponding to specific extensions (7, maj7, m7, 6, m6, dim7, 9, 13): once we've decided to extend a chord, this is how we decide which extension to choose (the "dim7" of course only applies to the "dim" base chord, since nothing in this file can change the basic triad that Songsmith chooses).  These get normalized, so for rows with only one non-zero value, it might as well be 1.0 (e.g., if an F major chord gets extended, it will always become an Fmaj7, there's no other choice, same with Bdim becoming Bdim7).

    So the question for fellow pop-music-theory enthusiasts is:

    ** What did we get right and wrong in this file?  What would you do differently? **

    I love talking about pop theory, hopefully others will find this question interesting!  And if you're a Songsmith user, feel free to play around with this file in your Songsmith directory to change the way Songsmith extends chords.

    But keep in mind that there's nothing you can do in this file to change the triads that have already been picked by the time this file is accessed (that would require editing the model files, which are discussed in other threads, and which enthusiastic users are also welcome to edit :)).

    -Dan from the Songsmith Team

    Saturday, October 19, 2013 11:46 PM

All replies

  • Old thread, but i was looking at the configuration files last and wondered how you came up with the values for the different chord extensions. Was there a lot of guesswork? I didn't notice any mention of it in the research papers.
    Wednesday, December 18, 2019 9:13 AM
  • Total guesswork... well, I guess one person's "guesswork" is another person's "artistic influence"... :)

    But in any case, yes, it was manual.  It's not only that we didn't have enough data to get meaningful statistics at the long tail of chord extensions, it's also that we don't expect the relationship between melody and chord extensions is nearly as tight as the relationship between melody and the core triads.

    If you have recommendations for a more systematic approach, share, and try it out!

    Wednesday, December 18, 2019 1:52 PM
  • I'm thinking about using music21 to count and tabulate chord extensions in my collection of scores. Is the number of substitutions written in stone, or can one add more? (I know there is a big catalog of them in a configuration file, which I don't have in front of me; is that the list of chords that the accompaniment engine understands?) And the base chords in columns A and B that are candidates for substitution--are only a total of fifteen possible? I'm assuming one would have to put a value in the State index column, whatever that might be.

    Edit: I tried adding extensions, and, while I was able to change chords in existing columns, when I tried putting a chord extension from chordextensions.txt in a new column W(with arbitrary decimal values), Songsmith refused to generate any extensions at all. Also, what's with the values in the T and V columns? There's no labels on those columns.

    • Edited by xhevahir78 Sunday, January 12, 2020 4:06 AM
    Saturday, January 11, 2020 7:03 AM
  • Re: T and V columns...

    In theory, every extension has two numbers associated with it: (1) a probability and (2) a minimum jazz factor value before you would see this extension at all for this chord.  These are commented at the top of columns G and H (associated with the dominant 7), and you can imagine those comments replicated into columns I/J, K/L, etc.  The minimum jazz factor isn't required, and it happens that the only chord extensions in the whole table that use the minimum jazz factor value (i.e., have non-empty values for this) are the I9 and the I13, which are represented in cells T3 and V3, respectively.

    Re: adding new extensions to this file (in column W)...

    In theory, this should work. For example, if you put "maj9#11" in cell W2, then a number between 0 and 1 in cell W3, everything should work as expected, with some probability of generating a Imaj9#11.  But no one has ever done this, and as a rule, totally untested code paths rarely work. :)  It's hard to say what actually happened here; it could be anything from your text editor changing the line break convention in the file to something related to the specific chord extension you chose.  If you really want to dive deep, you can enable Songsmith's debugging console, by starting Songsmith from the command line, with the "showconsole" parameter:

    songsmith.exe showconsole

    <o:p>...but this may be a deep rabbit hole...</o:p>


    Monday, January 27, 2020 10:16 PM