Owlsim (Windows, VST3) runtime crash

[eugarps]

Hi, I’m back looking for help again. I’ve got OwlSim building correctly, but when I try to load the .dll in my DAW (Reaper) I get a bad access in PluginProcessor.cpp trying to get the Patch Processor off the the StompBoxAudioProcessor instance. The call stack is as follows :

juce::ScopedPointer<PluginPatchProcessor>::operator PluginPatchProcessor() 
StompBoxAudioProcessor::getPatchProcessor()
Patch::Patch() 
SimpleDelayPatch::SimpleDelayPatch()
PatchRegistry::Register<SimpleDelayPatch>::construct() 
PatchRegistry::create(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & name)
StompBoxAudioProcessor::prepareToPlay(double sampleRate, int samplesPerBlock)
JuceVST3Component::preparePlugin(double sampleRate, int bufferSize)  
JuceVST3Component::setupProcessing(Steinberg::Vst::ProcessSetup & newSetup)

When I set a breakpoint in the setPatch(std::string) in StompBoxAudioProcessor I can see the patch processor getting instantiated properly, so I’m a bit perplexed as to what’s going on.

Something else odd I’ve noticed : PatchRegistry::create(name) is getting called multiple times even though I only have a single patch registered

Thanks~

[mars]

Hi @eugarps,
I think it’s normal for a VST host to instantiate a plugin several times, from what I recall.

The getPatchProcessor() call is static and relies on a juce:ThreadLocalValue to be set. Which it should be!

There’s some startup code which sets a default patch in the StompBoxAudioProcessor() constructor. Perhaps this is not called, or called from a different thread than calls prepareToPlay() ?

What you could do try is adding this line to prepareToPlay(), line 168:

void StompBoxAudioProcessor::prepareToPlay(double sampleRate, int samplesPerBlock){
  // Use this method as the place to do any pre-playback
  // initialisation that you need..
  instance = this; // add this line
  patchprocessor->setPatch(patches.create(currentPatchName));    
}

If that doesn’t work, check that patchprocessor is not null at this point.

ps apologies for the terrible naming, of classes and files, in the OwlSim project - it’s something that we meant to but never got around to clearing up!

[eugarps]

Hi, thanks for the response!

The call that I’ve been getting the crash on has been coming through prepareToPlay, but I’m not sure I’ve checked every time the setPatch method gets hit. Either way, forcing the initialization of the instance variable seems like a good enough workaround, so I’ll give that a short.

As for the naming, I’m certainly guilty of that myself so I don’t think I can hold it against you

[eugarps]

Success!