[VSTWrapper] Big situation here

Hi there,

I have searched into forum for this problem but do not find something so I am sharing it to us.
First of all, here is the environment : I launch a JUCE GUI application, using JUCE AudioProcessor wrapped as VST.
Here the problem comes :

  • I search for plugins in a directory, scan for them with PluginListComponent
  • When it scans, instance of plugin is created as ScopedPointer, and launch a initialiseJUCE_GUI()
  • When scan is done, the pointer to instance is deleted (cause it is a ScopedPointer) and calls for shutdownJUCE_GUI()
  • All my application closes itself because of that last call to shutdown…

Do you see where the problem is… Do you have a solution ?

Best regards !

If your plugin is managing to call the host’s shutdownJUCE_GUI() function, then your host and plugin need to be compiled without exposing their internal symbols!

The shutdownJUCE_GUI() func is called in JuceVSTWrapper class destructor.
How can I do not export external symbols as JUCE is compiled as DLL ?

Yeah, I know where it’s called from, but your plugin DLL shouldn’t be able to call that function in your host’s process! Most likely you’re just using a debug version of both host + plugin, with all their symbols exposed. Try a release build.

It does not change in release builds, and cause they share the same JUCE DLL, so they called the same shutdownJUCE_GUI()
So far, I have tried to build main application using JUCE DLL, and VST wrapped plugin with JUCE as amalgamated, and it works but they do no share same singleton (MessageManager, Logger…) ever.
So, what can I do in this situation ?

Oh, you didn’t say you were using juce in a shared dll!

Your plugins must be statically linked, they’re not designed to be aware that other modules may be sharing state with them.

Yes, i have finally done that : main app using juce as DLL, and VST plugs using juce statically (amalgamated).
No matter about non sharing singletons in fact, I used them only for Logger… and MessageManager does only communicate internally in the plugin itself.

Why not save yourself the hassle of messing around with DLLs and just link everything statically? There’s no sense in having an exe + DLL when it’d be significantly easier to build and install a statically linked exe (which would also take up less space and run faster).

Because for the moment, I do not know if separated libraries (core, gui,…) will be used dynamically or statically.

it’ll all be static.

I’ll expose your point of view in next meeting :wink: