VST3 createPluginInstance() Spectrasonics weirdness

Hi Guys,

This one is a bit out there!

I have some code here that scans plugins, which runs as a spawned process.

For Spectrasonics plugins this fails 90% of the time when calling formatManager.createPluginInstance(). The other 10% of the time everything works fine.

auto count = controller.getParameterCount(); on the EditColtroller is where it goes bang.

I know this is an outside chance but has anyone else encountered this or maybe has some idea of why this might be happening.

This is on OSX by the way.

Cheers

Andy

P.S. I have tested this in AudioPluginHost and can not replicate it, I also changed to using createPluginInstanceAsync() and ran the message loop but still get the crash. I have also copied the exact description used from AudioPluginHost via XML and used that just in case!

I haven’t tested these specific plugins, but some VST3s encounter issues when they are opened on a background thread. Make sure that the scanning process, and the call to createPluginInstance, happen on the main message thread. If you’re using ChildProcessCoordinator and ChildProcessWorker to communicate between the host and the scanner, avoid doing the scan directly in handleMessageFromCoordinator - use an AsyncUpdater or similar to run the scan on the main thread instead. You can look at the AudioPluginHost’s out-of-process scanning code to see how it’s done there.

Other than that, I’m not sure what to suggest. The problem could be undefined behaviour in your program, or a bug in the plugin itself. However, if everything works consistently in the AudioPluginHost then the problem is likely to be in your scanning code.

Hi @reuk

Thanks for the reply.

Everything is running on the main thread, the communication is via Mach, it is basically a port of an old scanner to use Juce.

I just knocked some basic code up of what it is doing and stuck it at the start of main to show the issue and it works fine!

  juce::initialiseJuce_GUI();
  
  juce::AudioPluginFormatManager formatManager;
  formatManager.addDefaultFormats();

  juce::XmlDocument descDoc(juce::File("desc.xml"));
  std::unique_ptr<juce::XmlElement> descElement = descDoc.getDocumentElement();
  juce::PluginDescription desc;
  desc.loadFromXml(*descElement);
  
  juce::String sErrorMsg;
  
  std::unique_ptr<juce::AudioPluginInstance> pAudioPluginInstance = formatManager.createPluginInstance (desc, 44100.0, 32, sErrorMsg);

Then later when it hits “the original same” code it fails, really weird, something must be getting messed up somewhere…

Aha, got it.

It works fine as long as VST3PluginFormat::findAllTypesForFile() has not been called. This is called to get the count to deal with child plugins.

The plot thickens!

I’m not sure if this is part of the problem, but if you’re not using an ‘application’ template, the message manager might not get a chance to actually start processing messages. initialiseJuce_GUI just ensures that the message manager exists, but it doesn’t start message processing.

The JUCEApplicationBase does this to start the run loop:

        // loop until a quit message is received..
        MessageManager::getInstance()->runDispatchLoop();

Failing to start the runloop could be problematic - plugins (especially plugin editors) will expect for the message manager to be running correctly.

I’d recommend using the JUCEApplicationBase (or something similar) to drive your plugin scanner, so that the message manager is set up properly, and is running during the scan.

Hi,
Thanks for the reply.

I handle the message loop myself during the scan.

I can replicate this exact behaviour in AudioPluginHost by calling VST3PluginFormat::findAllTypesForFile() before it calls CreatePluginInstanceAsync(). So the issue is there as well!

Unfortunately I can’t test this easily myself as Spectrasonics don’t provide demo versions of their products. Your best bet is to work out where the crash occurs. Is it inside the plugin itself, or in JUCE code? If the crash is inside the plugin, it’s either due to a bug in the plugin itself, or because the VST3 API has been misused somehow. If the crash is in JUCE code, it’s likely to be because the plugin is behaving in a way that JUCE doesn’t expect.

Hi Reuk,

Funny timing just looking at this again!

It is nothing to do with juce, the juce code looks absolutely fine to me, the crash is within the plugins.

In findDescriptionsAndPerform juce loops around the classes in the factory.

The LoadFroms for IPluginFactory2, IPluginFactory3 and IComponent are fine.

The issue in the plugin stems from the component->initialize / component->terminate block, if I comment these out then I do not see the crash when calling `createPluginInstance’ afterwards.

Everything seems to be being cleaned up correctly so I am at a bit of a loss.

If you’ve established that the problem is within the plugin itself, I’d recommend contacting Spectrasonics with this information. Hopefully they’ll be able to reproduce the issue themselves, and will be able to patch their products, or suggest a workaround.