(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.
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
}
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.
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.
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.
