Chord/Note handling relative to selected scale

borfo · September 11, 2014, 3:28pm

I had a thought on chord and note handling that would preserve chord progressions and melodies across all possible scales:

In 7 note scales, there are predictable basic chord shapes - there is a i, ii, iii, iv, v, vi, and vii chord - in a major scale, these are maj, min, min, maj, maj, min, diminished - in a minor scale they are min, diminished, maj, min, min, maj and maj. These chords are easy to find from the notes in the scale - simply take the root note of the chord, and add the notes that are 2 and 4 notes up from the root, looping around to start of the scale if necessary. eg: in C major, the notes are C D E F G A B - chord i is C major - C x E x G x x . Chord iv is G major - x D x x G x B - etc, etc. I believe this rule holds for all 7 note scales, and a friend who is much more of a music theory expert than I am says that the “2 steps up + 4 steps up” rule would produce good-sounding note combinations even in pentatonic or whole note scales, or other non-7 note scales.

Sometimes you might want to add a 7th, a 9th, an 11th, or a 13th - those notes would be easy to find algorythmically from a scale as well.

The SEQ’s force to scale feature defines a key and a scale root note.

I was thinking that a new track type could be developed for the SEQ - call it a ChordNum track type. Force to scale would always be active for this track type. With this type of track, in edit view for the main parameter layer, each step could be set to number 1 to 7, with an octave offset. That 1-7 number would be used to find the corresponding chord in the selected scale.

eg: If force-to-scale was set to C major, a “3” chord would play as E minor. If the user changed the force-to-scale setting to E natural minor, the 3 chord would now play as G major (the iii chord in the scale of E nat. minor) - this way, chord progressions would be preserved across different force-to-scale settings, but with the chords changed relative to the selected scale.

#############

New types of trigger layers could be added that would add 7ths, 9ths, 11ths, or 13ths to the chord. Again, these notes would be calculated based on the root note of the chord, and the force-to-scale setting.

Trigger layers could also be used to decide whether to play the 1st, 3rd, and 5th notes (the notes that make up the basic chord itself) - that way a user could choose to play only the chord root note and the 5th, for example.

If these 1st, 3rd, 5th, add7, add9, add11, and add13 trigger layers were parameter layers instead, an octave offset could be set, and “—” could mean “don’t play this note”. This would allow users to specify different chord shapes/variations.

##############

The advantage of this is that chord progressions would be preserved across different scales (eg: a i - iv - v would be a i - iv - v to fit whatever scale was selected), and only the key would change with the force-to-scale setting.

Currently, the way the chord track type is implemented, if you choose a chord type A with force-to-scale set to off, you’d get a c major chord. If you set force to scale to on, and choose the C major scale, you’d still have a C major chord. But of you change the force to scale setting (for example, moving up the major scales - C#maj, Dmaj, etc.), then the chord changes - it doesn’t stay a major chord (C# major, D major, etc.) because the force-to-scale rules are being applied to the component notes, changing the chord type. This means that if you set up, for example, a i-iv-iv chord progression, and then change the force-to-scale setting, you won’t have a i-iv-v progression anymore.

#################

It would also be useful to have a NoteNum track type - where instead of setting an absolute note (C#, F, A, etc), the user could choose numbers 1-7, representing the relative position of the note in the selected scale. These notes could also have an octave offset. When the force-to-scale setting is changed, the note played would be the note in the selected position relative to the selected scale, rather than the current implementation which takes an absolute note and moves it up or down one semitone to fit the selected scale.

EG: a “3” note in the scale of C major would be an E. If force to scale was changed to G harmonic minor, the note would become Bb (the 3rd note in that scale).

This would preserve melodies across all scales.

#################

I’m not sure how transposing should work with this sort of chord/note implementation. You’d want to transpose a chord or note up or down within the selected scale, clearly (so a “v” chord/note would become a iii or vii chord/note, etc.) - I’m just not sure how the input notes should be applied to accomplish this in an intuitive way.

Maybe these relative chord/note track types shouldn’t be transposeable. Since they are tied to the selected scale, maybe they would be best used as either fixed tracks to be played out to a synth without transposition, or as sources rather than targets for transposition/arpeggiation (ie: sent to a bus to arpeggiate or transpose another track).

#################

Thoughts?

T.K · September 11, 2014, 5:08pm

Some words how something similar could be achieved with the current firmware:

Currently, the way the chord track type is implemented, if you choose a chord type A with force-to-scale set to off, you’d get a c major chord. If you set force to scale to on, and choose the C major scale, you’d still have a C major chord. But of you change the force to scale setting (for example, moving up the major scales - C#maj, Dmaj, etc.), then the chord changes - it doesn’t stay a major chord (C# major, D major, etc.) because the force-to-scale rules are being applied to the component notes, changing the chord type. This means that if you set up, for example, a i-iv-iv chord progression, and then change the force-to-scale setting, you won’t have a i-iv-v progression anymore.

The force-to-scale function allows you to set the root note to the one which is received from the transposer.

Means: if you transpose from C to D (Track mode set to Transpose in the MODE menu page), the scale root will be automatically shifted by +2 and the played chords would still be proper major, playing the i, ii, iii, iv, v, vi, and vii and some other combinations depending on the selected chord number.

The transpose function has to be enabled for the track similar to this tutorial: http://www.ucapps.de/midibox_seq_manual_tut3.html

Only difference is, that you would set Root=Keyb in the MENU->Fx-Scale page.

Note also, that it’s possible to control the root note from a loopback track as well (there is a CC for this)

Are you already aware of this possibility, or is this new to you?

It would also be useful to have a NoteNum track type - where instead of setting an absolute note (C#, F, A, etc), the user could choose numbers 1-7, representing the relative position of the note in the selected scale. These notes could also have an octave offset. When the force-to-scale setting is changed, the note played would be the note in the selected position relative to the selected scale, rather than the current implementation which takes an absolute note and moves it up or down one semitone to fit the selected scale.

Well, easy: just use a drum track and configure the notes for the different trigger layers according to the chord members you want to play.

Enable force to scale, and take either a static root note, or set the root note to Keyb

Would this already solve your request?

Best Regards, Thorsten.

borfo · September 11, 2014, 5:44pm

Some words how something similar could be achieved with the current firmware:

The force-to-scale function allows you to set the root note to the one which is received from the transposer.

Means: if you transpose from C to D (Track mode set to Transpose in the MODE menu page), the scale root will be automatically shifted by +2 and the played chords would still be proper major, playing the i, ii, iii, iv, v, vi, and vii and some other combinations depending on the selected chord number.

The transpose function has to be enabled for the track similar to this tutorial: http://www.ucapps.de/midibox_seq_manual_tut3.html

Only difference is, that you would set Root=Keyb in the MENU->Fx-Scale page.

Note also, that it’s possible to control the root note from a loopback track as well (there is a CC for this)

Are you already aware of this possibility, or is this new to you?

Hm… I didn’t think the current firmware transposed chords relative to the root note of the selected scale. To duplicate the way I tested:

Set up a chord track with div=1, length=1. Put an “A”-type chord on the first step. Set force-to-scale on, and set the scale to C Major. The SEQ now plays a C major chord.

Move the force-to-scale root note up to C#, D, D#, E etc. The chord played doesn’t become C# Major, D Major, D# Major, E Major etc. Instead, force to scale seems to be applied to fit the component notes of a C Major chord (C E G) into those scales, so in the scale of E Major, the notes become C# E G# (or something similar, I’m not sure exactly how the force-to-scale rule works), rather than becoming an E major chord (E G# B).

But I’m not also transposing the note.

I guess you’re saying that I could change the force to scale setting, and then also send a transpose message to the track - so: set force-to-scale to E Major, and then also send an E to the track on a transpose bus… OR, set the force-to-scale root note to “keyb”, and then all I’d have to do is send an E to the track on a transpose bus or from a MIDI input.

Hm. I guess that does accomplish what I was thinking, although I’d argue that it’s less intuitive… I did realize you could set the root note to ‘keyb’, but it didn’t occur to me that keyb+transpose would work like this.

I was also aware of the CC for scale root… But with scale root set to “keyb”, can the root be changed by a note received from a bus track? If not, maybe “bus1, bus2, etc.” could be added as scale root settings… This would be easier than setting up a bus track for transposition, then also having to send a CC to change the scale root. But I guess a hardware loopback would also work for this…

Well, easy: just use a drum track and configure the notes for the different trigger layers according to the chord members you want to play.

Enable force to scale, and take either a static root note, or set the root note to Keyb

Would this already solve your request?

Best Regards, Thorsten.

Interesting… I hadn’t thought of this approach. I’ll have to try it. Sounds like it would probably work, although I’d also argue that it’s less intuitive than having a relative note track type. I guess the approach you suggest above for chord tracks (scale root=keyb, send transpose message to track) would also work to some extent. Haha… This device already does everything - I just need to figure out how to work with it in more advanced ways.

Anyway, just an idea.

T.K · September 11, 2014, 6:22pm

Hm. I guess that does accomplish what I was thinking, although I’d argue that it’s less intuitive… I did realize you could set the root note to ‘keyb’, but it didn’t occur to me that keyb+transpose would work like this.

Yes, it may be less intuitive (but that’s also a question of good documentation… you could help me to improve this )

Maybe it’s implemented this way because I thought a step further: it makes sense to control transpose and root note centrally (from loopback tracks or from an external keyboard).

Mostly you want to transpose the root note as well, but there are also cases where it makes sense to keep the root note as demonstrated in the tutorial.

I was also aware of the CC for scale root… But with scale root set to “keyb”, can the root be changed by a note received from a bus track?

yes: with root=“keyb”, the root note will be set according to the notes which are received from Bus1 (and only from this one).

Which means: if you would like to get an independent control over root note and track transpose, then send the notes which should target the transposer from another loopback track to different bus.

Best Regards, Thorsten.

borfo · September 11, 2014, 6:45pm

Thinking about it a bit more, I guess the current implementation does allow this relative chord/note functionality with the root=keyb in combination with transpose, although I can think of a few limitations that may be present in the current implementation. Most significantly:

While you could easily transpose a chord progression properly from one mode of one key to another key in the same mode (eg: chords in C Major could be transposed to E Major without losing the chord progression relative to the key/mode/scale), transposing from (for example) C major to D Dorian may not work like this, depending on how the force to scale rules work - all the chords/notes would be in key, but a i-iv-v progression may no longer be a i-iv-v progression if the force to scale rules don’t coincide perfectly with the way note positions shift between all scales. The notes in C Major and D Dorian are the same, but a i-iv-v in C Major is C-F-G, while a i-iv-v in D Dorian is Dmin-G-Amin.

If I’m understanding the current implementation correctly, by moving the force-to-scale setting from C Major to D Dorian and sending a transpose +2 semitones (D) message, For a i-iv-v progression in C Maj (A, B, C chord types) you’d wind up with D G A, which would then be forced into the D Dorian scale. Would the current force-to-scale rules force the notes in these chords to become Dmin-G-Amin? If so, and if this would hold across any scale, you’re a genius, TK.

While I still think a i-ii-iii-iv… implementation would be a lot more intuitive (particularly because in minor modes, transposed and scale-forced “ABC” chord types would often be playing minor or other non-major chords), the current implementation probably works with the root=keyb + transpose workaround, and conceivably works across all keys/scales/modes. Amazing.

I’m definitely planning on doing documentation work. I’ve already started planning a few articles for the wiki.

borfo · September 22, 2014, 2:31am

I’ve dug into the source code of the chord track type, and I understand how it works… I misunderstood how chord tracks work until now… I didn’t realize that all the chords were C variants. I assumed they were all chords in the scale of C, not all C chords.

I think the way chords are currently implemented is a bit crazy. I’m going to try to convince you that the implementation I describe in my first post would be more useful.

When not transposed or forced to scale, all of the chords and note combinations represented by A-P and a-p are variants of the C chord. A, B, and C are all C major, a, b and c are all C minor. I-N are C Maj6 … C Maj 12, etc. Here is the source for the chord variants (where 0-12=the notes of the chromatic scale starting at C):

static const seq_chord_entry_t seq_chord_table[] = {
  // 1 2 3 4 <----> (6 chars!)
  {{ 0, 4, 7, -1 }, "Maj.I " },
  {{ 4, 7, 12, -1 }, "Maj.II" },
  {{ 7, 12, 16, -1 }, "MajIII" },
  {{ 0, -1, -1, -1 }, "Root " },
  {{ 4, -1, -1, -1 }, "3rd " },
  {{ 7, -1, -1, -1 }, "5th " },
  {{ 0, 4, -1, -1 }, "R.+3rd" },
  {{ 0, 7, -1, -1 }, "R.+5th" },
  {{ 0, 4, 7, 9 }, "Maj.6 " },
  {{ 0, 4, 7, 11 }, "Maj.7 " },
  {{ 0, 4, 7, 12 }, "Maj.8 " },
  {{ 0, 4, 7, 14 }, "Maj.9 " },
  {{ 0, 7, 12, 16 }, "Maj.10" },
  {{ 0, 7, 12, 19 }, "Maj.12" },
  {{ 0, 5, 7, -1 }, "Sus.4 " },
  {{ 0, 4, 8, -1 }, "Maj.+ " },

  {{ 0, 3, 7, -1 }, "Min.I " },
  {{ 3, 7, 12, -1 }, "Min.II" },
  {{ 7, 12, 15, -1 }, "MinIII" },
  {{ 0, -1, -1, -1 }, "Root " },
  {{ 3, -1, -1, -1 }, "3rdMin" },
  {{ 7, -1, -1, -1 }, "5th " },
  {{ 0, 3, -1, -1 }, "R.+3rd" },
  {{ 0, 7, -1, -1 }, "R.+5th" },
  {{ 0, 3, 7, 9 }, "Min.6 " },
  {{ 0, 3, 7, 11 }, "Min.7 " },
  {{ 0, 3, 7, 12 }, "Min.8 " },
  {{ 0, 3, 7, 14 }, "Min.9 " },
  {{ 0, 7, 12, 16 }, "Min.10" },
  {{ 0, 7, 12, 18 }, "Min.12" },
  {{ 0, 3, 6, 9 }, "Co7 " },
  {{ 0, 3, 8, -1 }, "Min.+ " }
};

If you force the track into the scale of C major, many of those chord types become redundant - only note numbers 0, 2, 4, 5, 7, 9, 11, and 12 are in key (and 14, 16, 17, 19, etc.). Only the first group of chord letters (A-O) are in the key of C major - the rest are in C minor, and would be forced into C Major by the force-to-scale setting. (P would be forced-to-scale and become something else, since note 8 is out of key.)

It’s also worth noting that all of these chord variants are basically the same thing anyway - a “C” chord is composed of the major harmonics that are most prominent when we hear a “C” note anyway - the 3rd, 5th, 7th, 9th, etc. are all in that original C note anyway. When we play a C and its 5th, that’s just a slightly different way of playing a C Major chord, where one of the harmonics is de-emphasized. And a C Maj 7 just emphasizes one of the other harmonics that’s there anyway. So this long, hard to remember list of 32 chord variants is really just a list of 32 small variations of pretty much exactly the same thing.

Since the chord implementation is so complex, I imagine nobody uses it without force-to-scale enabled - trying to keep track of the transpositions and chord letter selections required to keep a chord progression in key without force-to-scale enabled seems like an impossible task to me anyway.

So, assuming chords are only used with force-to-scale enabled, and if force-to-scale always renders at least half of the chord shapes (A->P +p or a->p +P) redundant because when they are forced to scale, they become the same as the other chord shapes (when in a major key, a-o become A-O, and when in a minor key the reverse happens, and in either case, P and p are out of key and would be transformed into something else). So, disadvantage #1 is that more than half of the chord shapes are redundant.

Disadvantage #2 is that these chord letters are non-intuitive and hard to remember. Particularly confusing because they don’t correspond to note names, which are also letters. (eg: Chord “A” is not an A Chord)

Disadvantage #3 is that the current implementation relies on the force-to-scale rules to properly transpose notes up or down in particular circumstances to ensure that the right chords are produced. I haven’t looked too closely at the force-to-scale rules, but even if they do perform correctly in all possible circumstances, always creating the proper chord, this would seem to be a convoluted implementation, with an extra possible point of failure.

Disadvantage #4 is that in order to play a chord progression, you need two tracks - one chord track, and one Bus track to transpose the chord track.

Disadvantage #5 is that in order to play a chord progression, you have to know the notes in the scale you select. Not everyone using the SEQ will have a particularly good grasp of music theory. (I know I don’t…)

Take your example in Tutorial 3 for example.

http://www.ucapps.de/midibox_seq_manual_tut3.html

There, you play a progression in C Major - Em-Am-C-Em. It is relatively simple to do that, because it’s in the key of C.

1: set force to scale to C Major

2: Enter a bunch of Chord letters in the chord track - all the letters correspond to combinations of the notes in a C Maj. Chord (you would have gotten more or less the same results if you entered a-o minor chord variants, since they’d be forced-to-scale to C Major and become major chords anyway)

3: send E-E-A-A-C-C-E-E to the chord track on a bus

…Transpose + Force-to-scale turns that into an Em-Am-C-Em progression.

######################

In the Key of C Major, that progression is a iii-vi-i-iii progression (Em, Am, and C are the 3rd, 6th, and 1st chords in the key of C Major)

Much more complex though, if you wanted to play a iii-vi-i-iii progression in the key of Eb Harmonic Minor, because while everyone knows the notes in the scale of C Major (and could figure out the notes corresponding to a iii-vi-i-iii progression), not everyone knows Eb Harmonic Minor so well…

Notes in Eb Harmonic Minor are: Eb F Gb Ab Bb Cb D Eb

Chords in Eb Harmonic Minor are:

i: Eb Minor (notes: Eb Ab Cb)

ii: F Diminished

iii: Gb Augmented (notes: Gb Bb D)

iv: Ab Minor

v: Bb Minor

vi: Cb Major (notes: Cb Eb Gb)

vii: D diminished

So, a iii-vi-i-iii progression in the key of Eb Harmonic Minor is: Gb Augmented - Cb Major - Eb Minor - Gb Augmented

To play that progression, you would have to:

1: set force to scale to Eb Harmonic Minor

2: Enter the same bunch of chord letters in the chord track, all of which would correspond to C Major (or enter lower case letters a-o, it doesn’t really matter since it will be forced to scale anyway)

3: send Gb - Cb - Eb - Gb to the chord track on a bus

…Transpose + Force to scale turns that into the desired progression.

BUT, in order to do that, the user has to know the notes in Eb Harmonic Minor. The current chord implementation can’t be used effectively by users without a good grasp of music theory - you have to know the notes in whatever key you select in order to use the chord track effectively.

With the current implementation, the chord parameter layer isn’t really doing much of the hard work in playing a chord progression… It’s left to the user to choose the chords that fit the currently selected key. All the chord track does is takes the input note, plays some combination of root, 3rd, 5th, etc. of that note, and forces the result into the chosen scale, which creates minor, augmented, diminished, etc. chords as appropriate. But the user’s doing the hard work of remembering what notes are in the key in the first place.

And it would become even more complicated if the user changed the force-to-scale root note, for example by choosing the “keyb” option. You could easily wind up producing all kinds of off key music if you didn’t plan everything very carefully…

#######################

If a i-ii-iii-iv-v-vi-vii chord track implementation (as I describe in my first post) was used, then to accomplish what you did in your tutorial:

1: Set force to scale to C Major

2: enter a iii-vi-i-iii progression in the Chord track

Done.

To transpose that progression to Eb Harmonic Minor:

1: Set force to scale to Eb Harmonic Minor.

Done. No music theory knowledge required. Transposing into any of the other 166 scales on the SEQ would be just as easy.

borfo · September 22, 2014, 2:39am

The chord table could be constructed something like this for a i-ii-iii-iv-v-vi-vii implementation, where #s 1-7… correspond to the notes in the currently selected scale (eg: C Major - 1=C 2=D 3=E 4=F 5=G 6=A 7=B 8=C 9=D 10=E 11=F …etc.)

static const seq_chord_entry_t seq_chord_table[] = {
  // 1 2 3 4 <----> (6 chars!)
  {{ 1, 3, 5, -1 }, "i " },
  {{ 2, 4, 6, -1 }, "ii " },
  {{ 3, 5, 7, -1 }, "iii " },
  {{ 4, 6, 8, -1 }, "iv " },
  {{ 5, 7, 9, -1 }, "v " },
  {{ 6, 8, 10, -1 }, "vi " },
  {{ 7, 9, 11, -1 }, "vii " }
};

This table would also “just work” in Minor keys and in all modes (phrygian, lydian, dorian, locrian, etc.). Inversions, tonics, note combinations, weird chords (add7 add9 add11 add 13, etc.), etc. could be added in a variety of ways, maybe with other chord letters on the main chord parameter layer (1a, 1b, 1c, 2a, 2b, 2c, etc…), or maybe with trigger layers.

Anyway… What do you think?

I may take this on as a project eventually if I can’t convince you that it’s a good idea, but I think this might be a bit complicated for a first MIDIbox coding project, given that my knowledge of C is pretty crap… I’ll probably try a few simpler things before this. How complex do you think it would be to implement this as a new chord track type? Would it be easy to check seq_scale_table (in seq_scale.c) and the selected force-to-scale root note and then calculate the chord offsets from that? Are there any obvious technical barriers to implementing this?

…sorry about all these giant wall-of-text posts… Kind of a complicated idea to explain in fewer words.

lukas412 · September 22, 2014, 12:34pm

Wow very nice analysis. I know crap about music theory, but I do generally get less than desirable results when I start fussing with transposing chord tracks that are forced to scale. Now knowing how they are working I can see why and can maybe change the way I work with them, but that being said knowing I will generally need to know all the notes in a scale it seems a more daunting task. Very curious to hear TK’s response to this one.

thanks,

Luke

T.K · September 22, 2014, 6:21pm

I come to very good results with the current chord mode strategy (even w/o force-to-scale), but maybe only because I think different

E.g. I find it important that also single notes can be triggered, not only a combination of notes.

The enumeration (A, B, C) isn’t a big problem if you learn them, the full name will be displayed at the right upper corner.

On the other hand it isn’t a big deal to add an alternative chord mode which follows a different strategy, but I’ve to warn you that it also needs to be efficient (e.g. searching for the next note in the scale would result into a iteration which consumes a lot of processing time - too much to guarantee stable sequencer timings).

So, would be nice if you could elaborate a bit further how an efficient note selection could look like, and then I could give you feedback if it is feasible with the given timing constraints.

Best Regards, Thorsten.

borfo · September 23, 2014, 1:54pm

Cool. I’ll dig through the source over the next while and try to understand how everything works and come up with a proposal.

Am I understanding the current implementation correctly? When the SEQ is playing, every time it hits a step, it runs SEQ_LAYER_GetEvents(). When the current layer is a chord layer, it hits the chord CASE clause, and runs SEQ_CHORD_NoteGet() four times to translate the chord letter (A-P or a-p) into notes. This translation occurs every time a step is played (in other words, the chords are not stored as notes, they’re stored by name - as the equivalent of “A-P…” - and translated into notes when played.)

To implement this i-ii-iii-iv… proposal, a “case SEQ_PAR_Type_numChord” clause would have to be added to SEQ_LAYER_GetEvents(). If that clause ran a translator function that required similar processing power to running the current SEQ_CHORD_NoteGet() function four times, that would be efficient enough for the SEQ to maintain timing?

…and when I’m in SEQ_LAYER_GetEvents(), seq_core_global_scale_root and seq_core_global_scale would be the right place to look to find the currently selected scale and root? Or would I have to call SEQ_CORE_FTS_GetScaleAndRoot() to get the current selections?

T.K · September 23, 2014, 4:38pm

Am I understanding the current implementation correctly? When the SEQ is playing, every time it hits a step, it runs SEQ_LAYER_GetEvents(). When the current layer is a chord layer, it hits the chord CASE clause, and runs SEQ_CHORD_NoteGet() four times to translate the chord letter (A-P or a-p) into notes. This translation occurs every time a step is played (in other words, the chords are not stored as notes, they’re stored by name - as the equivalent of “A-P…” - and translated into notes when played.)

Yes… but they are stored by encoded value.

Each step in the parameter layers provides a 8bit value. The Chord number and octave is decoded into this value.

To implement this i-ii-iii-iv… proposal, a “case SEQ_PAR_Type_numChord” clause would have to be added to SEQ_LAYER_GetEvents(). If that clause ran a translator function that required similar processing power to running the current SEQ_CHORD_NoteGet() function four times, that would be efficient enough for the SEQ to maintain timing?

SEQ_LAYER doesn’t need a table reference for the number of notes.

It’s sufficient when SEQ_CHORD_NoteGet returns a value < 0 if no additional notes should be played.