More CV Expander?

[Marizu]

Hi. I'me really digging the Nerdseq, but I was just curious when the More CV Expander is likely to be available.


Sorry to bug you,
Marizu

[XORadmin]

I am curious as well ;-)

It is produced...it needs still some weeks until it is as i want it. Too many things to do. But i will do my best that it is going to be ready soon!

[Marizu]

Cheers! I appreciate the number of updates that you have been making.
I saw the More CV in Brighton and have been thinking about it ever since!

[AXN_NL]

Looking forward to this, any updates?

[XORadmin]

Busy with it right now.

And as i'm on my way, i think about how the screens should look like. In the first place and my proof of concept it is like this:
Note1 Note2 Note3 Note4 Note5 Note6 ||| Note7 Note8 FX1 FX2 ||| FX3 FX4 Groove
(where ||| is a screen change, so 6 columns notes in the first screen etc...)

I think that would directly limit the usual MOD output (values) to only the FX columns.
What comes in my mind as 2nd would be sharing the note columns for either MOD and note. That would be possible, but it would limit to maximum 128 MOD values (in a 10 Volt Range), which is very close to the regular note range, so it is actually useless.... Fine MOD values are of course still possible via the FX column (or paches later on).

So another idea was then that you can set up the Expander in a track as either 8x notes (can be set up as 1>8 or 9>16) + the 3 FX + Patch + Table + Groove OR
as 4x MOD(fine, can be set up as 1->4, 5->8, 9>12, 13>16), 3FX, patch, Table, Groove. This can be set up differently of course again for each track which is dedicated to the CV expander.
In both cases, Notes or fine CV values can still be generated through the FX column or the patches (once patches are activated, which allows to manipulate all 16 values at the same time).

The main issue is as usual the limitation of the possible Columns per pattern and the values behind it. It is simply not possible to have one column for each Note or MOD (Notes use 1 byte, MOD use 2 bytes, FX use 3 bytes, Table, Patch and Groove use 1 byte and the max is 21 bytes per track....just as technical details).
Maybe you got a better idea or agree that this is the best possible?

[AXN_NL]

Maybe others can chime in, I am fairly new to this all

[timh]

Thanks for all the hard work!
The 8xNotes or 4xMods sounds good to me - but maybe a 4xNotes+2xMods+(fx,patch,table,....) would be an option: It would only be one mode and assigning it to two tracks would give the same as one 8xNotes and one 4xMods - however, with only only one track assigned to the expander one would get the best of both worlds (4 voice poly plus some modulation).

[XORadmin]

Thanks for all the hard work!
The 8xNotes or 4xMods sounds good to me - but maybe a 4xNotes+2xMods+(fx,patch,table,....) would be an option: It would only be one mode and assigning it to two tracks  would give the same as one 8xNotes and one 4xMods - however, with only only one track assigned to the expander one would get the best of both worlds (4 voice poly plus some modulation).

Sounds also good. Keep in mind that even with 8x Note, you still can do multiple modulations additionally.
Also, every MOD can be a Note as well.

[XORadmin]

I could actually squeeze 2 more notes in case of 4xMOD additionally to it, so it could be 4xMOD+2Note+fx,patch,table,groove.
The mix could be 5 Notes and 2 MOD.

[XORadmin]

OK, i have to cancel the new idea of different screens for on CV expander. There is one thing i didn't think about which makes it impossible to handle:

Just imagine you would use like the 8xnote on one track and the 4x mod on another track. The patterns are incompatible to each other as they have different columns. But since patterns can be shared between the CV tracks, it would just not be possible to for example show a 8x Note pattern in a 4x MOD track and vice versa.
Not even talking about playing these patterns in the 'wrong' tracks.

It looks like that It'll be one CV screen then, just like with the other types.
I will think about any other possibility to still make it happen...without breaking the generic implementation.