Static objects and VST

Audio Plugins
1

jules: you mentioned when i ran into problems with the previous release, that it’s not a good idea to have static objects, becasuse of some problems

could you give me/us a clew on what can/should be static and what can’t be.
what sort of objects String/AudioBuffer/Component, i mean i don’t know how bad is it that i declare static local String’s in my methods and should i perhpars use all dynamic where possible.

2

No, don’t use static strings! Static pointers are probably ok as long as you make them DeletedAtShutdown or clean them up by reference counting when the plugin instances are deleted. But avoid any kind of object that will get automatically deleted when the statics are cleaned up, because that’ll happen after Juce has been de-initialised, and will probably make a mess.

3

Hello,

my question is related to this so I took the liberty to ask here.

Is it in general okay to have static objects in a plugin? When the hosting application opens two instances of my plugin would that not mean that the static object is shared between those?

From what I read this definitely applies to dynamically linked libraries (Plugin.dll -> OtherLib.dll -> static object).

Thanks,
Dan

4

They *may* be shared but it's not guaranteed. They probably will be if the host opens the same format of your plugin with the same architecture but I wouldn't rely on this. More and more hosts these days are sandboxing plugins e.g. BitWig has an option to load every plugin in its own process. These certainly won't share statics.

What are you trying to do? You should probably avoid using statics as I've only ever seen them cause problems (not least because they're unlikely to be thread safe and hosts will be calling your methods from all sorts of threads).

5

But avoid any kind of object that will get automatically deleted when the statics are cleaned up, because that'll happen after Juce has been de-initialised, and will probably make a mess.

What sort of deinitialised juce objects would cause issues in a String's destructor? For instance if I declare

// MyAudioProcessor.cpp
namespace
{

const String xmlID ("xmlID");

}

 

6

Okay that is basically what I expected. My intent is rather to understand the liability that comes with it. Not every third-party library is completely free of statics so I try to understand which cases might require a modification and which do not.

Thank you for your answer
Dan