Live Play Chord Detection Enhancements
I have a few other ideas that might be really useful for live input, particularly for the situation of playing a one-note (or one-octave) left-hand with a soloing right hand:
A mode where the root note determines also the mode of the chord (e.g. you tell ARP you're in the key of C major, and you play an E as the root note, the resulting chord should be an E minor as that's the correct chord for the key, etc.) -- a lot of times sampling the root and then some random lead note above it gives just one or two notes to the list that ARP picks from when playing over it, and that's a little frustrating. This would work really well with one-finger and split.
A mode where the notes are only "sampled" once per beat, so you can noodle away furiously but hit the chord you want on the beat without messing up the arp during the beat. Same thing for bar. (Would be nice if this could be chosen along with the above mode, so you could have 1-finger dynamic chord selection sampled on the beat or bar, for a walking bassline to input the structural chords.)
Similar to the above, but slightly different: in normal arp mode, a per-arp option to use a simple "best match" heuristic to choose the appropriate chord from the sampled notes, instead of using only the sampled notes.
Yep, I get the fallback option (that's what I'm using) - it's simply that when you want to sit down and noodle, or just put together a quick string section for backing up a cover song or something, these might be just the ticket. Fortunately simple algorithms cover the major use cases, but I know this is going beyond the scope of ARP in a lot of ways; still, having it be at least "modal aware" would be a very handy trick, if you can swing it. On that note...
I can think of a few simplified ways to do some of these, sure! I've given some thought to this idea for some of my own projects.
First idea: modal chords from a single root (#1 above):
For this mode, you simply need to know what is considered the tonic, and what the fundamental mode is (e.g. C Maj, F min, etc). If you don't want to go with modes, as you may not, you could choose one of the defined scales as a starting point. There are (at least) two possible simple algorithms for this, for explanation's sake let's take the case of choosing (beforehand) D as the tonic (how to set this is up for discussion - my suggestion is simply choose it and the scale on the keyboard on top of ARP and then whatever you play is going to be relative to that tonic note and chosen scale in this mode):
A. Setup: You choose one scale (any scale). For example, let's say you choose a scale that has C#, D, E, F#, G, A, B in it - the DMaj scale. For each new root note live-played in:
Get the scale degree: Look at the root note of the live input and determine the degree on this scale relative to the tonic - if you play a G, for instance, it's the 4th scale degree because D (1) -> E (2) -> F# (3) -> G (4).
Build the note pool: Then just build the note pool from the chosen scale with that played root as the scale root and skip every other scale degree (so G->B->D). If the player hits an off-the-scale note (say F) you have a couple choices (but the simplest and most rational, at least with respect to tonal/modal music and left-hand roots is concerned, is to round down unless the last root was a half step higher, in which case round up) to get the scale degree (F (F#) -> A -> C#). This is simple because it works with any single user-defined scale and the offsets are therefore fairly predictable and controllable. It also works more or less the way a modal chord theorist would generally expect, with minor quibbles around how to handle the off-scale roots. For playing classical-ish, rock/pop covers esp. oldies, etc. this would work well because that's generally how that music was composed.
B. Setup: You choose one scale (any scale).
Get the scale degree the same way as in A1.
Then simply rotate the scales defined in ARP by that many positions. That's the scale you play, with the played root note being the basis for the scale. E.g. if you choose D as the tonic, and minor as the scale, and you play the above G, you'd just scan the scale notes to find out how far away G is from D, and on a minor scale that's also the 4th degree, so you'd set your note pool to whatever is defined in the sus4 chord position, with G as the root note of the scale. This handles the off-scale notes slightly differently - you'd round up or down (a heuristic here might be round down unless the previous root was a half step higher, in which case round up - this covers walking up and down nicely), choose the nearest appropriate scale, and build that scale with the off-scale note as the root -- so the F# would again choose whatever's defined in the sus4, but as an F#sus4. This lets the user set up the scales they want for the various rotations.
The advantage to A is that it's very simple to use and does a fairly expected "modal" job. It doesn't handle more than three notes in a scale pool though as it can't detect whether a sus/aug/etc should be thrown in. But it'll play nicely with whatever is being live played in, where the user can be as chromatic as they want in the right hand over it.
The disadvantage to B is that it requires a lot of customization of the scales before it makes any modal sense at all. But it leads to a lot more creative potential for non-modal playing. Its best combined with saving scales on a per-preset basis, for that obvious reason.
The quibbles here are over what to do with off-scale notes, but they're minor quibbles because it's not too common that the root notes played will be off-scale in most western tonal music unless it's just a walking bassline (and the heuristic covers that well enough), and there's never consensus on how to handle them anyway - when they do happen it's often case-specific. Having this mode at all is, to me, far more useful for most western cover music and play-along than not having it. There are other ways to solve those problems too, various "play along" algorithms do similar things with chord theory. I've kept my suggestions intentionally bog-simple to make it straightforward to muck with on an embedded cpu.
Third idea: "best match chord"
This one is pretty simple too and requires only a quick scan of all chords and a ranking algorithm.
Take the note pool of played notes, let's say you've got D, F, A with D as the root.
Look at each scale in turn, map it to this root, and score it +1 point for every note it has in common, -1 point for every note it doesn't have in common (this is one simple algorithm, it works well, but it's not the most intuitive, still it clashes quite minimally with what's played). Take the highest scoring scale and choose all the notes in that scale pool as the chosen. In case of a tie, choose the "left most" scale (from Maj to aug) as the winner. You might futz with the algorithm a little (maybe it should be -0.5 or -0.9 for notes not in it) to get slightly better tie-breaking, but for the most part this does the job nicely.