Thanks for all your amazing work with the book!
I was wondering if there is a way to "smooth" the frequency changes of the WTOscillator, if you do a rapid change of frequency with the slider/knob you can notice the "steps" going from the current frequency to the target frequency.
Do I have to do a modification like an interpolation in the setFrequency() method?
Thanks very much!
I gone about smoothing parameters a couple ways. The first is based off the same concept as an envelope follower (check out the "Difference Equation" on the bottom of page 429 in Will's book). Basically the slider becomes the audio input, and the output is the value you want to end up using (in your case the frequency). Thus you can set attack & release times.
The second way is something I call ROCC (Rate of Change Clamp) & is nothing more than a few if-else statements, and is based off the same envelope follower difference equation.
All this does is limits how much the parameter can increase and decrease by a STATIC value (maxChange). It's a render-based function (gets called every sample period). You could cook the maxChange variable based on the sample rate but I haven't implemented that in my attached example.
Here's the .h & .cpp of this implemented within a volume control plug-in: https://www.dropbox.com/s/7pcciwio88edjwy/VolumeSmoothed.zip
Hope that helps! Let me know if you find a different way to do it!
I really appreciate all your effort explaining how to do the parameter smooting and also the source code you shared with me, thanks very much!
On the other hand, I was experimenting (the day before you posted the answer) a way to do the parameter smooting in a very simple and efficient way, that fixed all the issues I had with the frequency slider.
Basically I made a small class for the parameter smoothing, these are the most important parts of that class:
void ParameterSmoother::initialize(int sampleFrames)
previousSample = 0.0f;
currentsSample = 0.0f;
delta = 1.0f / sampleFrames;
float ParameterSmoother::smoothParamValue(float sample)
// One Pole Lowpass Smoothing
float smoothedValue = previousSample + delta * (currentsSample - previousSample) ;
previousSample = smoothedValue;
currentsSample = sample;
In few words, I did the parameter smoothing with a one pole low pass filter, which is kind of linear interpolation and my delta step is one over the buffer size (in my case I was using 512 samples), but could be any buffer size.
I think the way you do the parameter smoothing works fine but I don't know how much the double branching (the first if and then the ternary operator ? : ) affects the CPU performance because it is executed every sample.
Let me know what do you think, thanks for the advice!
Nice! I'll have to try your method. Yes a LPF (smoothing filter) would work very well. In a way it seems quite similar to the envelope follower difference equation.
So is ParameterSmoother::smoothParamValue called every time a new audio buffer arrives? That would certainly be more efficient then per-sample rendering.
Indeed, it is very similar to the enveloper follower difference equation =), and not, smoothParamValue( ) is called every sample in order to keep track of the rate of change between each sample to hear the smoothed sound change.
I'm testing now a way to avoid the calculation inside smoothParamValue( ) if the slider is not moved, I tried different things like checking if the sample is but I'm getting some "clicks" when I move the slider. =(
I've posted some similar information in another zipper noise thread:
Most Users Ever Online: 152
Currently Browsing this Page:
Guest Posters: 1
Newest Members:IgorVish, Arjuna, TomMilne, BaiJin, MarioG, caozbm, audio_coder, coder, Levioter, VariableCook
Moderators: W Pirkle: 470
Administrators: Tom: 74, JD Young: 80, Will Pirkle: 0, W Pirkle: 470