PluginProcessor constructor is called twice by audio plugin host

My audio plugin [0] works… sometimes. The problem is that sometimes it gets initialised incorrectly.

I run it in JUCE’s “Plugin”. When I add my VST3 plugin to the host, I notice that my PluginProcessor’s constructor gets called twice. So my private initialiseSynth() gets invoked twice, and finds that it has already been initialised before. Sometimes it survives this fine, other times I end up with segfaults when I rely on the data that I’ve constructed.

Here’s the exact code of my PluginProcessor:

These are the two stack traces I captured — the two times that my constructor was invoked. It seems that juce::VST3PluginFormat::createPluginInstance() is the common ancestor. Once inside that function, it constructs my audio plugin twice. Is this normal?

[0] It’s a simple synthesizer that takes MIDI input, uses fluidsynth to render each block through a soundfont.

It’s quite normal for hosts to scan a plugin on startup which involves loading it. Also keep in mind that your plugin could have any number of instances open at any one time so you need to make sure you can deal with that. Are you relying on static variables or some kind of singleton maybe?

I don’t have any singletons or statics.* one suspect is the fluidsynth library I link against, but that doesn’t obviously rely on singletons/statics either (the entry point is to request that it construct an instance for you to use).

*Disclaimer: I am not a C++ expert

The problem is, that you don’t initialise your initialised variable.

Either change this line to

bool initialised = false;

Or set it to false in the constructor.

In C++ all simple types need to be initialised manually, since the compiler assumes, it might not be needed.

Same goes for the other variables as well, don’t assume they have a certain value.

1 Like

wow, thanks for investigating! I’ll try this out. that would also explain why channel sometimes began its life set to a large random number…

About C++ and initialisation, watch Scott Meyers at the d-conf (obviously). It is very insightful and entertaining as well, if in a hurry start at ca. 6:12 minutes:

1 Like

I have the same problem, I tried something like this:

   if (isConstructorInitialised)
       //do stuff
       isConstructorInitialised = false;


   if (!isConstructorInitialised)
       //do stuff
       isConstructorInitialised = true;
 //in header file:
 bool isConstructorInitialised = false; 	

but when constructor gets called for the second time, the boolean is reset to default value so the if statement is useless :confused:
My synth is a drum sampler, and all files are loaded twice…
any suggestions?

Don’t actually do anything time consuming in the constructor. (Start doing it later instead.) It can easily happen that the host constructs the plugin, immediately destroys it and then constructs it again. Also, if there are multiple instances of the plugin in the host project, the host of course calls the constructor for each instance separately.

1 Like

It is impossible to write code, that calls the Constructor of the same object twice, afaik.
If you see this code executed twice, that means, that there are two instances of your plugin. You must design your code, that this is not a problem, since the user can decide to have several instances of your plugin on different tracks.

This plus all the other advices posted by others, to make the constructor as short as possible and defer loading to later asynchronously


It is impossible to write code, that calls the Constructor of the same object twice, afaik.

That’s not true, it seems - I’m witnessing it now.

When I have an instance of my plugin created in the AudioPluginHost, but no GUI open, If I then open the GUI I will see my MainContentComponent’s constructor called once, followed by the destructor being immediately called, followed by the second call to the constructor, after which the GUI opens.

So even just opening the GUI results in the whole thing being created, destroyed, and recreated.

Wow! Surprised the hell out of me. When you think about all the components being laid out, addAndMakeVisible etc. and all of the component initialization that is taking place there, that seems kind of worrisome. I’m not sure I see how to defer all of that to later. Wouldn’t the resized then be called out of order?

I suspect that this quote referred to the impossibility of calling the constructor twice for the same instance of an object.

I mean, if your MainContentComponent is being created at address 0xSOMEWERE, the constructor for that instance at that address will be called exactly once, then never again.
If you see it being called a second time, it will be for another instance, at a different address 0xWHATEVER.

What you describe instead is that two instances of MainContentComponent are created (therefore their constructors called) in rapid sequence.

That may be worrisome, but if you think about it, it is exactly how many hosts deal with plug-in UIs: when you open the window to show it, they create the Component, when the window is closed, it is destroyed.

Of course your plug-in must be designed to withstand whatever amount of such editor destruction/recreations, because that’s what DAWs do.

1 Like

Thanks for the clarification.

But I wonder why it’s necessary for a host to initially create and destroy the editor once when opening the editor, and then finally create it once more to display the editor. The plugin is already loaded, and has been scanned etc. and is functioning. We’re just opening the editor.

You would need to ask the host developers why they are doing that. In any case, if you are not doing anything unreasonably heavy in your GUI’s constructor and destructor, it shouldn’t be any problem. The create/destroy cycle should happen in a few dozen milliseconds.

OK: JUCE Developers, why does the AudioPluginHost do that? :smile:
That’s sort of tongue-in-cheek… but still…

That’s anecdotal, but I remember Fabian mentioning, that hosts might create a throwaway editor to check for resizeable flags and bounds limits. Might be completely bollocks made up by my unreliable memory.
But to cut it short, you have to code so it doesn’t create a problem.
Some people, who do heavy stuff or license checks in the editor, delay that with a single shot timer for half a second (Timer::callAfterDelay()).

1 Like

Thanks for that useful function I wasn’t aware of! Not that I need it at the moment, but could come in useful.