Hope you won't mind me weighing in on behalf or Graywolf, since he's really busy & this topic actually worth discussion indeed.chk071 wrote: ↑Sat Mar 27, 2021 10:35 am I know that this post is kind of old, and you're not a super fan of the idea, but, would it be possible to revise this request? The thing is, when you add 5 keys to have 10 keys in total for the key select lane, it would be possible to use BlueARP like a "classic" arpeggiator, being able to use all 10 fingers. I sometimes definitely use both hands for arpeggios, when I use "normal" arpeggiators, which work in the way like when you use the BlueARP with the key select feature. It would be great to have, IMO. I love BlueARP for its more step sequencer like approach, but, I sometimes always have a need for "regular" arpeggiator funcionality.
Before delving into thinking adding new lanes, features or changes, it is crucial now to know that current BlueARP's (plugin) GUI structure matches & must keeps matching BlueARP's (the hardware) visual feedback & parameters. As well as making future proof updates seamless process, knowing that BlueARP now is being used inside Unify (by PluginGuru) under license agreement, and that's not the only case. From now on, users of BlueARP of any form, must be able to go back & forth across BlueARP forms.
Now let's get back to "traditional arp note cascade scanning" request and how to implement it.
Technically, what we want to achieve is to have an input detector that scans pressed keys up to 10, and then applies needed function & filtering/sorting.
What we have now in BlueARP, regardless of step seq matrix that shows (K1 to K5) this is not the real challenge actually "more on that in a couple of paragraphs". The limiting barrier is under the [Key input pre-filter] These 5 slots are the max range of input / output notes in BlueARP, not only that, but they make the backbone of the algorithm (to define scale, chord, calculate sorting).
However, with new revamped algo of still unreleased version of BlueARP, changing things is not going to cause huge mess
i.e. it is possible to define 5 extra keys 
for special purpose use of traditional arp. Theoretically it is possible to add 10 input keys, and visibly shown as two groups of 5-slot cascading e.g.
In keys pre-filter: (C1, D1, F1, G1, A1)
then followed by
: (C2, D2, F2, G2, A2)
With that we have K1, K2, ..., K10
well not really. On seq matrix, there's no room to host these new K6, K7, ..., K10
But it is not a bad news, the other seq matrix view [step type matrix], can squeeze in new modifier lane. To achieve the traditional arp cascade scanning, it is like [Chord type] but obviously broken to single note at a time.
Thinking reasonably, we can use the already exist [Missing keys substitution] parameter to specify what happens if only 1 note is being held one, should it repeatedly played at same interval, or bounce octaves, or what happens to playback sequence if we fill step type with [Cascade] for two slots, then [Norm], then back to [Cascade] should the note sorting starts all over again, or from where it was in previous slot. etc. Interesting
Having said that, clearly it is lots of thinking, time to translate thoughts to codes, and hours of testing. Yes this is a nice creative feature, but yes this is also a freeware product. If users want this feature, it is greatly helpful to share ideas here as well as support the development with ideas & donations. Maybe it can happen indeed, maybe it is better & easier to make another plugin. Let's see.
