rnd optimization

[tester]

Here is the original modified one. This one has your adjustement for pulse driving.

Few things to pay attention to:
- in design - it will run for less than 1 sec or more than 2 hours (generally, I use 0.01s resolution).
- one input setting could drive all 4 channels (decay is the same for all) // not present here
- must have (linear) fade in - it is set to create "ding" (usually 1-3ms) or fading effect (lenght is shared with fade out)
- for fade out: it is curved according to middle point gain (dB)
- must have a trigger node, to reinitialize (or resync) on demand
- must be fast
- could have some sort of gain compensation if during fade out - lenght is changed (shordened) // not presetn here.

*

Hmm... I just discovered, that this part is not my CPU eater. Hmm... Doing brief comparative tests in FS - it seemed that changing that rnd part will bring back about 4% of CPU. But on operating design (EXE) - performance is the same. I lost one unit from running somewhere on-the-go.

MyCo, these mono4 pack/unpack stock prims - are they something to pay attention to (i.e. worth to change in to asm parts, like I borrowed from Trog)?

Should the "specp.fsm" be optimized somehow in terms of performance? I'm checking all things I added recently.

//edit:

Actually, after reviewing the design in action a little bit deeper, mod on randomization theme and switching from m2f's into multi-channel graph2f's (while stream values are in use, green values are sent back to the interface) - gives slight improvement, but still - it's "almost" (i.e. fraction of what was expected). I switched that mono4 pack/unpack parts into slowpacks where I could too, but I don't know if these changed anything. I guess, after optimizing "specp.fsm" things may get back to glitchless on this machine; it's another "maybe", but worth to check.

//edit2: Stupid me. I think I can push the "specp" through mono4. //edit3: ...and after doing so - Initial performance is back again. Can this one be optimized even more?