Re: rnd optimization
Posted: Fri Jun 14, 2013 11:29 pm
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?
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?