(Update: The crashing/coeficent errors don’t happen unless it loads from a saved state. Loading the vst with initial values works fine. I suspect that it may have something to do with the way I am intialising the coefficients with the LinearSmoothedValue objects.)
I’ve been having trouble getting my plugin to initialize properly for a while now… sometimes it causes these crashes depending on the saved state of the parameters. Sometimes if the values are loaded in reaper from the last saved state it will load fine and other times it will not. It seems to have something to do with the initial values of my filters or the sample rate but I’ve triple checked and the range of values I am giving them are fine.
The plugin loads into the daw’s but crashes the “debug” mode in Visual Studio on loading of the plugin.
That led me to want to check the intialized sampleRate in prepareToPlay and when that didn’t return anyvalues I decided to just check if prepareToPlay is being called and it looks like it isn’t.
Another symptom that may be related is when I load the plugin in Plugin Doctor or Plugin Audio Host the image knobs (custom slider class with custom lookAndFeel) show fine but when I load into Reaper or Ableton the knobs are missing with the ui being sluggish, and only the juce slider fallbacks show. If I close the plugin window and reopen it my knobs reappear and the ui becomes responsive again.
Here are the errors and the callstack I’m getting, thanks for taking a look.
I’ve also included the project file.
ParametricEq.zip (7.0 MB)
It seems your updateParameters() is called from the constructor, when there was no chance yet for prepareToPlay for being called.
It still crashes the same even without that. That was an attempt to try forcing the filters to initialize because it seems like either the sampleRate or the values going to the coefficients aren’t initialized.
The DBG’s I’m using to fetch the samplerate in updateFilter functions are returning 0 so I’m guessing that’s the problem. Strangely, the plugin crashes on load before prepareToPlay ever gets called so I guess that’s why it’s returning 0.
I tried removing the updateParameters from the constructor and just left it in the prepareToPlay and it’s giving a slightly different error although prepareToPlay is being called now and the sampleRateis being set.
We never used
prepareToPlay(). We use
getSampleRate() in the constructor for initialization. After that, we check in the
processBlock method for sampleRate changes. I never had any issues with this:
auto currentSampleRate = getSampleRate();
if (currentSampleRate != _sampleRate)
_sampleRate = currentSampleRate;
// initialize and update DSP with the new sampleRate
Hmmm, it seems like the values initialise to 20 (cutoff) and 0.5 (q) but then they zero out for some reason right before crashing at load.
I wonder if it has to do with the LinearSmootherValues I’m using.
Interesting. What about block size? prepareToPlay passes you that.
So far, our algorithms do not depend on the block size.
Cool. So use a fixed size internally, then if necessary process sub blocks? I’ve been considering that approach myself.
This jassert is to protect against negative or zero frequencies and frequencies above nyquist. Which one is it? What is the value of currentFrequency?
Oh I see the DBG says frequency is 0, the coefficients cannot cope with that says the jassert
Exactly. We do most processing on a sample basis.
Yeah, something is definitely going on with the initial values. I managed to get it to load properly and in the debug I am getting good values at the last stop before setting the coefficients. The problem seems to lie in the way it is restoring the saved state of the plugin between sessions.
If I load the plugin with intial values it doesn’t crash but if I load from a saved state I get the jasserts about the cutoff, frequency, and samplerate.
This seems to be tied to the other problem where the response curves dont update to the intial state on load either. The sliders and the handles I am using to drive the curves are all updated but the response curve doesn’t update to match unless I change one of the values by changing the parameter and then it snaps to position.
I’m not sure if it has something to do with the currentValue/nextValue of the LinearSmoothedValue object and the way it interacts with initializing the coefficients for the filters or something else.
I’ve tried initializing the coefficients, the values themselves, and triggering repaints everywhere I can think of the get the curves to refresh on load but it seems like it’s a more fundamental issue than just painting.
ParametricEq.zip (7.0 MB)
Here you can see the behavior. First the plugin starts with the juce sliders instead of the custom lookAndFeel until the window is reset in Reaper… then you can see the behavior of the resonse curve handles and how they need to be manipulated in order for them to snap/conform to the actual saved state rather than the initialized state.
If I should risk a guess maybe messing up normalised and denormalised values at some point?
I’ll take a look again but based on the fact that the curves and parameters work perfectly outside of initialization I’m not sure.
I think I’ve got it now… what I needed to do was initialize the LinearSmoothedValues properly as I suspected… here’s how I did it.
First I grabbed the treeState parameters and then redefined them so I could set the smoothed values. I called the updateParameters function after intializing them in the prepareToPlay.