Hi all,
I just saw a discussion on another forum (link), and I was curious how do you people deal with parameter smoothing.
Right now I was just doing something like here:
http://u-he.com/vstsource/files/sync_x.cpp
but that may not always work (for instance: some hosts divide audio blocks when new events arrive).
I was thinking about one pole filter to smooth parameters - something like:
current_value = coeff1*new_value + coeff2*old_value
but for a lot of parameters that can take some CPU.
Is there any other possibility?
jD
Parameter smoothing
-
- KVRAF
- 2460 posts since 3 Oct, 2002 from SF CA USA NA Earth
I have a function Update() that I call every N (usually 64) samples regardless of the (potentially varying) VST block size. In Update(), among other things, I compute the needed delta to get a parameter from its current value to the most recent new parameter value in N samples. Then every sample I just do: param = param + delta. It adds N samples of latency to the controller response[1], but that's just over one millisecond for N=64 at 44KHz.
[1] As opposed to latency to the overall audio output, which of course we're not talking about.
[1] As opposed to latency to the overall audio output, which of course we're not talking about.
Last edited by Borogove on Mon May 30, 2005 1:25 am, edited 1 time in total.
-
- KVRian
- 1325 posts since 1 Sep, 2004
johnDOE wrote:Hi all,
I just saw a discussion on another forum (link), and I was curious how do you people deal with parameter smoothing.
jD
But seriously, I thought about that theme again and again. So finally I probably did develop 3 or 4 different solutions in my live for that problem.
The first was somehow very easy solved by simply calculating a destination value and an increasing value based on the blocksize. But that finally introduced some problems, if the blocksize changed all the time. And the speed of interpolation was directly dependant from the blocksize itselfes, which finally caused undefined behaviour with different hosts and drivers.
Other solutions then were to develop interpolators (small fast assembly code blocks) which calculated the same principle with editable speed of reaction time. I also tried to find a solution to skip some calculations. But skipping 64 samples and calling the update then would never the less result in strange (but fast) steps, which are infact audible, because influencing the frequency spectrum of the proceeded audio material in a wrong way...
I actually know that, because I tried it. But I cannot give you any guaranty, that everybody will be able to hear that...
The last development regarding that theme is a smart user editable mechanism to interpolate the parameters with high resolution. He can completely switch it off.
Special attention was applied to the (pre)calculation algorithm, so that there only some few calls are required to update the value with low overhead. The precalculation executes at receiving a parameter change.
There is finally only very small difference in speed, if you switch it off.
And it works (on the synthesizer implementation) very close thogether with the 3 * 6 modulation matrix I developed (it's therefore all per sample calculated - maximum acouracy, finest smoothing).
To implement an opcode, which gives you interpolation with editable speed, shouldn't be any problem (even for a newcomer). That's really only increasing positive or negative amount in dependance of the speed and probably doing that in decent intervalls...
The users want it, even if it slightly eates up some more performance. But digital steps are inacceptable today.
So, begin to code now...

