Could any of you who have hacked the firmware run your brains over this idea. I had an idea that it would be cool to add a third envelope that would be a software approximation of a makeoise maths. It is basically an AD/AR type envelope with variable rise/fall times and a variable slope from log through to exp and it can be made to cycle.
The actual code for the envelope value calculation isnt too complex I wouldnt think. x^n where n goes from 1/64 to 64 would be a loose approximation of curved, non linear shapes.
The interesting bit would be fitting it into the UI and into the mod matrix
the 4 params on the pots could be attack time, decay time, slope shape, and cycle mode (off, on like an lfo, on retrig at end of decay).
The maths is a pretty cool module that makes for some interesting modulation opportunities. It would be cool to have something similar in the software of the shruthi. I might investigate this myself (once I get finished soldering), but I thought one of you guys might be able to do a sanity check ahead of time.
Is the same lookup table used for all rise and fall stages? (A,D&R)
Would the reflection thing work? In my head the reflection would have to be through the diagonal.
Depends on what you have in your LUT… Yes, it’s the same shape for A, D&R
Pointing to the LUT is a good idea, because this envelope curvature feature could be implemented cheaply by:
- Using a more pronounced concave segment in the current LUT.
- Crossfading between the LUT and a mirrored version of itself. The crossfading factor will give the envelope concavity.
uint8_t step = InterpolateSample(wav_res_env_expo, phase_);
You just need to add this after this line:
step = U8Mix(step, ~step, shape);
Where shape is between 0 and 255. 0 will give the present shape ; 128 a straight line ; 255 a different shape, like on the Cwejman adsr-vc2.
Maybe sample the output of the maths and use it as source for the current envelopes LUT, not sure it would change much though?
Maths is cool, but im not shure it would translate well into the digital domain, who dares wins though…
It’s doable, CPU is not a problem since envelopes are refreshed every 40th regular sample. My concerns are that the UI is already very complex, that the patch data structure is fully packed so these new parameters won’t be saved, and that it’ll be listed out of place in the modulation matrix.
Yeah, I struggled to see an obvious place for it in the UI. I can envisage how to layout the adjustment for the params for the env itself, but hooking it in nicely would be tricky. The only other thought I had was to add another param to the existing envs that specified a type (ADSR vs function generator) and re interpret the existing param values. That way (at least for the patch storage) only a single bit would be needed.
first of all: i did not hack the firmware (and i don`t have any idea, what i am talking about)
i am not sure, if there is enough cpu time left for another lfo/env. i bet, if there was, there would be another env or lfo already.
also it would interfere with the patch data structure unless you stick all the parameters in something that already exists. (like implement it as a new lfo waveform and use rate and attack for the A and D values of the new thing. etc…)
there were already a few features implemented this way. which are all awesome, but make the interface a bit quirky for beginners because the new features were implemented in a way avoiding to change patch structure. (like the “stepmix” mode for example)because of this, i think this would be a good hack, but maybe not good as a feature in the “official stable version”
still i like the basic idea and i think it would be nice to have something like that
also you can already get looping ENVs by using the envtrigger destination in the mod matrix i think. maybe you can also get something like the exp slope thing with the operators (not sure right now but i think i will try that)