Suggestions for mod matrix + navigation

i’ve spent some time with my shruthi now, and even though i haven’t even touched the sequencer and arpeggiator yet, it’s already giving me enormous pleasure. it’s fun to program and sounds fantastic! still i can’t help thinking of some ways to make it even better:

first of all, i think the modulation matrix could use some more modulation destinations:

  • modulation depth: what i currently miss the most is the ability to modulate the depth of other modulations to allow for a bit more complexity. i think the best and most flexible way to do this would be to add modulation depth (or “modulation amount” in shruthi nomenclature) for some of the “patch cables” as modulation destinations. maybe for the first 4 or 6 - “mam1” to “mam6”?

  • envelope release time: i would love being able to modulate the release time of the two envelopes - “rel1” and “rel2”!

  • portamento time: yes, this is definitely something i would love being able to modulate with lfos or the internal sequencer etc. but more importantly, it would allow you to use a virtual patch cable with an offset “modulating” (i.e. setting) the portamento time in order to save it with the patch! i think that alone would be worth adding “porta” to the mod matrix! (or can this already be done somehow?)

also, i must admit that i find the order in which the modulation destinations appear in the mod menu a bit confusing. why is vcf cutoff first, but vcf resonance 11th? i would suggest putting modulation destinations in the same order as they appear in the other menus, first the osc settings, then the mixer settings, then the filter settings etc. the same applies for the modulation sources, of course.

finally i have a suggestion for making menu navigation even better. i think it’s already very intuitive, with just one minor issue when cycling through the env + lfo pages: led4 and led5 look the same when editing env1 and lfo1, or env2 and lfo2. it’s not really much of a problem, but i think this could be easily improved. the most simple way would be the following cycle:
xo (env1) - ox (env2) - xx (lfo1) - oo(lfo2)
but i think it would be even cooler if while editing an lfo, one of the led would be blinking to indicate the rate of that lfo. the cycle would then look like this (with “y” indicating a blinking led):
xo (env1) - ox (env2) - yx (lfo1) - xy (lfo2)

what do you guys think?

thoughts anyone?

olivier: what are the odds that any of this might find its way into future firmware releases?

Regarding the modulation of the envelope stages: I will give it a try but I don’t think it’ll work well. The reason is that there’s a relatively computational expensive step to update the envelope slope increments (which includes a scary 16 bit x 16 bit multiplication). If the envelope is controllable by a modulation source, we’ll have to do this every time the control signals are refreshed. This might apply to portamento though I am not sure… Of course I hate myself to have used a lowly AVR when I see feature requests like this, but it’s pretty much the only chip cool to code with and in a DIP package…

Regarding the modulation of the modulation amount: A feature I plan to implement are 2 or 4 slots for operations on the modulation sources: you pick a modulation source A, a modulation source B, an operation (multiply, min, max, bitwise…), and the result appears as a new modulation source.

Regarding the order of the modulations: there are two ways in which I can change it. One way is to add a layer of indirection in the UI code to change the order. I’d rather dedicate the 100 or 120 bytes of code it’ll add to something more useful. Another way is to actually reorder it directly, but this will break your patches in memory… There might be a time where the changes in the OS will require the patch format to evolve anyway (and at that time, I’ll have to provide a conversion/backup utility). So I’ll keep it on my list.

As for the blinking LFO LEDs, this was implemented indeed in a very early version. The first tester didn’t like it at all because with slow LFOs the LED could be off and there was no way of knowing which LFO was active (having the modulations LED off because of a slow LFO is not a big deal: it’s pretty clear to know what’s being edited by looking on the screen ; but for LFO there’s nothing on the screen that tells whether LFO 1 or LFO 2 is active). I have no opinion on this, let’s see what other people have to say…

For the LFOs it would be nice havin one LED permanently lid to indicate the Page, the other blinking, indicating the LFO. Another idea would be having the LED at max for 1/3 of the time, the other time indicating the lfo output.


oh well, if modulating env release or portamento time is too computationally intensive, then i guess we’ll have to live without. at least they can still be sequenced externally via midi cc. which controller number controls portamento time, btw? it doesn’t say in the reference manual.

but if doing this via the mod matrix won’t work, would it be possible at least to save portamento settings with each patch instead of globally? seems to make more sense to me.

> A feature I plan to implement are 2 or 4 slots for operations on the modulation sources: you pick a modulation source A, a modulation source B, an operation (multiply, min, max, bitwise…), and the result appears as a new modulation source.

wow, that sounds awsome! it’s a bit more complicated than what i had in mind - but so much more versatile! i can see some really weird modulations coming up.