new mode: CONTROL MODE

[pureParticipant]

i propose a third mode besides CHORD and DRUM: CONTROL. CONTROL is very similar (identical?) to how drum mode works with the exception that it sends CC not notes. so it will be like alpha/beta on steroids and a great companion to both other modes.

[rempesmParticipant]

That would absolutely make the Zaquencer over the top awesome.

Put that in combination with some MIDI compatible FX pedals and come out swinging.

Don’t know how feasible this is in terms of limited memory but fully seconded.

[fabiParticipant]

i’d love that. i could have one zaquencer do note tracks and the other do CC automation.
then again, i have yet to understand the midi alpha and beta function properly.

[pureParticipant]

@rempesm: memory shouldnt be a problem as literally the only difference to DRUM mode is that the number pairs produced by the BCR dials get formatted as [cc number, value] instead of [note, velocity]. all within the same 7 bit range.

@fabi: although a 2nd zaquencer probably never hurts you would get very far with just the 4 tracks you have now:
track 1: 16 drum tracks
track 2 + 3: monophonic/chord sequence
track 4: 16 tracks of sequenced parameter modulations

and then there would be still 4×2 more cc’s!

[alien_brainParticipant]

how would it differ from what is already possible?

in the scenario above, the obvious bottleneck is that track 4 can only be set to 1 midi channel.

are you guys aware of the 2 ‘controller’ lanes per track that we already have? they can be cc, pitchbend or aftertouch. you can set any of the other tracks to the same midi channel and use their controller lanes on the same midi target. nice and versatile. can someone explain to me what this proposed mode will change?

[pureParticipant]

i wrote “it will be like alpha/beta on steroids” so i am obviously aware of alpha/beta.

my proposal is to increase the number of controller lanes (from 2 to 18 per track) by introducing a new mode, which is technically almost there (because, as i wrote, the value pairs which are now formatted to note commands in DRUM mode would simply need to be formatted as continuous controllers). so it won’t “break” the concept.

the bottleneck you describe doesn’t exist because the functionality doesn’t exist yet. you are correct that right now each track sends to only one midi channel. to use the full power of the proposed CONTROL mode it would be necessary to add the possibility for the user to define the midi channel individually per controller lane. this is -technically- as simple as the functionality to define different midi notes in DRUM mode right now.

[alien_brainParticipant]

sounds pretty cool. if its possible im all for it.

[ChristianKeymaster]

While I understand that this would be great, unfortunately it is not at all as easy as pure suggested. Please let me explain: a controller message is made up of 3 bytes. So is a note message, so I understand where your thinking is coming from, pure. The thing is that there is a lot of trickery already involved to have the drum mode in there at all. You see, while for every drum hit there is a full midi note being generated, the way it´s stored internally is reduced to the absolute minimum information needed.

So the note number + midi channel always comes from the Global menu settings. and then we don´t use the 7 bit for velocity, but only one bit for on/off of the drum note (using velocity 127). So actually for every step we use only one bit of memory per drum instrument, or 16 bits for all 16 drum instruments.

To generate a CC message is much more expensive in flash memory. Even if you´d move midi channel nr and controller number to flash (like it is now), you´d still need all 7 bits for each generated CC value. Even for a regular track we only afford that much for pitch, velocity and Alpha/Beta parameters, where it´s definitely needed. The memory for all the other params (mute, delay, length etc) is already reduced to their value ranges.
So for 16 additional CC messages we´d need additional 16 x 6 bits (we already have one) in flash per step! or 16 x 6 x 32 bits = 3072 bits for 32 steps. And there is no possibility of squeezing that amount in at all. As I wrote in the ratcheting thread, with a lot of effort it might be possible to gain one additional bit per step.

Please let me know if this is still unclear and I´ll be happy to delve in deeper.
Cheers!

[fabiParticipant]

i was thinking it wasn’t possible cause the drums weren’t velocity sensitive. glad you verified it, cause i wasn’t sure i understood it. i was thinking i had simply missed the velocity sensitivity for the drums, somehow.

[pureParticipant]

thanks for all the explanations, zaq. i knew you crammed the memory but i didn’t expect you crammed it that tight, wow!
i overlooked that drum mode is not velocity sensitive otherwise i would have already had the suspicion that there is no space anymore. i was assuming it uses the full 7bit so it would have only be 4 more bits for the individual midi channels. hmm…

ok i will think about something for the one last bit you are offering

let me hi-jack this thread with another – hopefully related – question: the zaquencer offers 192 patterns, right? this sounds like a LOT of memory to me! my question is: if you would cut this down to spare space – is this memory you could use otherwise, for example to implement new features? or are these memories unrelated to each other?

[fabiParticipant]

i was wondering the same thing about the 192 patterns…

to drive this further off-topic, i finally got my second zaquencer running. yiipieeeeheiyeah, schweinebacke.

[alien_brainParticipant]

i sorta knew it, just didnt wanna say it. 192 patterns is a lot. maybe the number could be cut down in the name of implementing new things…

[ChristianKeymaster]

Well yes, the flash memory is enough for 192 patterns.
If that number would be cut, it would mean more memory for the individual pattern.
The only thing that makes sense from the internal architecture etc. is to cut it down to 96 patterns, which would mean double the memory per pattern.

The thing is it´s hard to take away existing features. In another thread people were wondering the same thing with the patterns and the were voices against cutting the number of patterns, where the 192 patterns were a deciding feature.

[alien_brainParticipant]

can you make a poll?

[alien_brainParticipant]

…unless you dont want to of course. its your thing, do what you wanna do.

[Author]

Posts