Any ideas on how I could achieve a chord memory that stays in scale?
Lets just take C major as an example. If you play the basic triads you’ll get
C, Dm, Em, F, G, Am, Bmº right?
Using the existing harmonise modifier one could map a major chord with intervals of +5 and +9, or a minor chord with intervals of +4 and +9, but as you work up the scale the intervals have to change for the chords to stay in key so I’m not sure this is achievable.
What we’d need is a modifier which harmonised by scale offset, rather than semitones.
Obviously the key thing is that one needs to think in terms of scale offsets rather than semitones. Obviously this mainly applies to the harmonise modifier as for single note inputs the scale remap will work, but I’d imagine there are other cases where thinking in terms of scale first would be helpful.
I did pretty much the same thing in my own experiments, though I only did the in-key notes as my intention was to do chords across the drum pads on my master keyboard (Novation SL MK3) so didn’t need to account for the other note values.
My inspiration came from the chord mode on my Elektron Digitakt, which has a lock-to-scale mode where you can play the scale chords from the root note, but ironically I noticed last night that the new Novation LaunchKey controllers have a scale mode built in which I hope they’ll backport to the higher end controllers like mine too…
As you’ve seen, this method works fine but it’s obviously a pretty long-winded way to achieve it for a generic use-case…
It’s worth considering doing the output via a second virtual port though as you could then transpose in your initial step from physical->virtual and then transpose back in the last virtual->physical too and then it would work for any major key…
Still, fingers crossed per Giedrius’ reply that Blokas can find a more elegant solution as I’m sure a proper implementation where internal pipes can use a scale-relative offset rather than semitone values would be useful for all kinds of other applications too…
Also, if in your example you put the scale remap modifier in the first row, you won’t need your additional transpose steps to deal with the out of key notes, as the notes going into the virtual will already be locked to the major scale.
That’ll save 5 rows, plus all the additional transpose steps in each row…
Also, I just thought, it can be simplified further, as the range filter can do multiple values, so in the example of C major you only need one row for the major chords
so the range value would be ‘C3,F3,G3’ for the majors
‘D3,E3,A3’ for the minors
and a single ‘B3’ for the diminished chord.
As the filter can have 9 parameters you can do 3 octaves in one, i.e. ‘C2, F2, G2, C3, F3, G3, C4, F4, G4’ for example.
Nice to see you “working” on your initial idea… with my example.
My initiative was to try things, find ideas, “happy accidents”, I’m all up for streamlined implementations (ahah initial idea was - why not individualise each note, not looking at expenses for how many pipes used…my example shows each line of pipes what each note is doing)
Although I’m reusing this examples for much more elaborate available chords, without the restraints of pipe Scale Remap.
