Possible arpeggiator modes/directions

[pld]

Howdy all,

so while porting the 'chord' mode from MIDIpal yesterday I was playing around with these, but I'm not sure how useful they are since I'm coming at this mostly from a code point of view
I forget if these have a well-defined name, so if they do let me know...

1. cycle
Played notes: C-E-G
Result (up): C-E-G E-G-C G-C-E repeat...

2. cycle with octave (supercycle?)
Played notes: C1-E1-G1
Result (up): C1-E1-G1 E1-G1-C2 G1-C2-E2 repeat...

If that makes sense
They seemed to work for Down, U&D, and with the regular octave parameter as well.

Downside: an explosion of "Dire" entries if I add "UpCy", "DnCy", UDCy", "UpSc", "DnSc", "UDSc".
So during my morning commute I thought about just adding "Cycl", with a separate sub-page for editing, e.g. [ Dire (up,down,u&d), Octv (yes/no) ]
The "arp step sequencer" as suggested in the firmware thread is something I need to give some thought, but now that I'm thinking about it  it might provide similar effect if it has some kind of "offset" parameter as well. Hm...

Suggestions welcome

[martindunne]

sounds amazing, cant wait

[Xavier]

Downside: an explosion of "Dire" entries if I add "UpCy", "DnCy", UDCy", "UpSc", "DnSc", "UDSc".
So during my morning commute I thought about just adding "Cycl", with a separate sub-page for editing, e.g. [ Dire (up,down,u&d), Octv (yes/no) ]

I have to try it before really understanding but that look very interesting.... 
I don't understand what Sc is in ""UpSc", "DnSc", "UDSc".

Please no aditional sub-page, specialy in the engine menu which is already busy.
Adding direction entries is OK.
I'm currently working on the plugin, and i have to stabilize the number of parameters. Extending an existing parameter is easy.

[pld]

I don't understand what Sc is in ""UpSc", "DnSc", "UDSc".

Supercycle. I'm open to better names Maybe UpCo (Cycle octave?) The normal 'octave' setting works on top of that so it should go up seamlessly.
If I have time I can try and record a test later.

Please no aditional sub-page, specialy in the engine menu which is already busy.

Doh! Coming home I had a whole plan for the "arp step sequencer" combined with the cycles, but that would be 1 control row + 2 if enabled 
I agree that the engine menu is getting a bit overloaded... but where else?

[Xavier]

Supercycle. I'm open to better names Maybe UpCo (Cycle octave?) The normal 'octave' setting works on top of that so it should go up seamlessly.
If I have time I can try and record a test later.

I don't get how Supercycle is different from Cycle with octave >=2.

Please no aditional sub-page, specialy in the engine menu which is already busy.

Doh! Coming home I had a whole plan for the "arp step sequencer" combined with the cycles, but that would be 1 control row + 2 if enabled 
I agree that the engine menu is getting a bit overloaded... but where else?

Sound interesting...
Where else ? I don't know. We may hide them by default and activate them in the setting... I'd like not to have 20 rows in engine menu when new users turn on their preenfm for the first time.
Anyway those new rows won't be in 1.00.  But that must not prevent you from coding it ;-)

[pld]

I don't get how Supercycle is different from Cycle with octave >=2.

Hm, how to describe... Writing it out is probably better:

Played: c1, e1, g1
UpCy, octave=2: [c1-e1-g1 e1-g1-c1 g1-c1-e1] [c2-e2-g2 e2-g2-c2 g2-c2-e2]
UpSc, octave=2: [c1-e1-g1 e1-g1-c2 g1-c2-e2] [c2-e2-g2 e2-g2-c3 g2-c3-e3]
UpSc, octave=1: [c1-e1-g1 e1-g1-c2 g1-c2-e2] repeat

Where [] is one cycle which ends when each played note has been used as the starting note, then the arpeggiator octave changes.
UpCy muddles around in the played notes, but UpSc arpeggiates the ascending chord inversions, so when the arpeggiator switches octave, it continues seamlessly.
If that helps
You can get the same result by manually playing the chord inversions with 'Up' direction, for 'cycle' you'd have to used 'plyd' and hit the right ordering.

Hm, maybe 'supercycle' should be 'auto inversion' or something, and I'm admittedly not convinced 'cycle' is useful, but it was easy to implement both

Sound interesting...
Where else ? I don't know. We may hide them by default and activate them in the setting... I'd like not to have 20 rows in engine menu when new users turn on their preenfm for the first time.

Yeah, it's getting a bit overwhelming...

Anyway those new rows won't be in 1.00.  But that must not prevent you from coding it ;-)

I'll probably do it soonish because otherwise I'll lose my train of thought Then we can re-evaluate where/if to put it.
You can cherry-pick the 'chord' commit out of the branch since it shouldn't have any other implications.

[pld]

Quick braindump after I did a quick&dirty implementation of the step sequencer without a UI:

• How about 'rotate' or 'permutate' instead of 'cycle', and 'shift' instead of 'supercycle'?
• Doing these mods in the arp step sequencer (ASS ) will work, but it might be even cooler to have both so they add to each other
• Which ties in with the request to have arp parameters modifiable via matrix, so we have the additional parameters 'hidden' as matrix destinations?

[Xavier]

How about 'rotate' or 'permutate' instead of 'cycle', and 'shift' instead of 'supercycle'?

Is one really clearer than the other ;-)

Doing these mods in the arp step sequencer (ASS ) will work, but it might be even cooler to have both so they add to each other
Which ties in with the request to have arp parameters modifiable via matrix, so we have the additional parameters 'hidden' as matrix destinations?

I don't know what you plan to do for the arp step seq.
What will the values of the steps control ? Will the BPM and Gate of the step seq be used ?
If not, you'll have to read directly the stepSeq values.
If using the output through the matrix you'll get the Gate effect as well as some smoother.
Smooter :  The step seq never jump from 0 to F, it goes through all values, to prevent audio click when targeting MIX or Oscillator frequency.

[pld]

Is one really clearer than the other ;-)

Ok, not really But they sort of map to the ROR and LSR type instructions...

I don't know what you plan to do for the arp step seq.

It started with a suggestion in the firmware thread:
...possibilities of an arp step sequencer where for instance you could program it to play user arp 1 four times then user arp 2 three times etc.
So maybe less of step sequencer, more of a pattern chain. That also gives bettern acronyms than ASS...

My thinking was 1-4 slots/links consisting of { pattern, count, modifier, value }.
The modifier would affect some parameter of the arp/pattern while that link was playing.
Some modifiers I had off the top of my head were

• transpose: +- value
• step: change ordering of notes; normal is step 1 (c-e-g), step 2 gives (c-g-e-c-...)
• division: somehow modifiy the division parameter
• octave: modify octave parameter

How this might tie in with the matrix I'm not too sure, the vague idea was adding matrix destinations that do the same thing as the modifiers. Or something

So yeah, it's a bit half-baked, but kids these days call it agile 

[Xavier]

I was about releasing a 1.B13 after having fought against git merge branch.
I realized that the Rotate and the Shift mode both sound like SHIFT :
> "SHIFT modes rotate and extend with transpose, e.g. UP: C-E-G -> E-G-C1 -> G-C1-E1 -> repeat"

I checked in your code and i did not see any think that would make a difference between Shift and Rotate.
Do i miss something ?

[pld]

No, I missed something; I pushed a fix to the branch. The last "cleanup" commit was a bit too aggressive

[Xavier]

OK thanks.
1.B13 just uploaded. 

[pld]

Great. Sorry about that...
Do you think it's worth having arp parameters controllable by CC?
I did a quick test and changing patterns on-the-fly worked. That might be easier than an internal sequencer...