AudioProcessorEditor constructor is called two times

[pajczur]

Hello,
I’ve just found out that in JUCE AudioPluginHost my plugin AudioProcessorEditor constructor is called two times each time I open plugin window.

I have updated Projucer, and I’ve just made fresh compilation of AudioPluginHost too, and there is the same issue.
I still don’t know how it is in other plugin hosts, I will check today evening, but now I would like to ask if any of you experienced the same behaviour?

Of course I am sure I have only one instance of my plugin launched in AudioPluginHost.

There is also strange that even I don’t open plugin window but only right click on my plugin in AudioPluginHost to see context menu for example to remove plugin, then also AudioProcessorEditor constructor is called (but only once).

I’ve also found that each time plugin is launched the getStateInformation() is called before setStateInformation(). But it’s not problem because there is some other MemoryBlock as input, so when setStateInformation() is called I get proper data.
Due to order of calling getStateInformation() I’ve found such thread:

FL Studio 20 : VST 3 : getStateInformation called when plugin is being created

UPDATE Of course its a bug in our code, explanation at the bottom. We’ve encountered an issue with our plugin on both Mac and Windows using FL Studio 20 and VST 3 where it is calling getStateInformation BEFORE setStateInformation when a plugin is being instantiated. This means that any state we saved previously is lost, because this creation time getState is overwriting it with nothing. Has anyone encountered anything similar? All other VST3 hosts appear to be acting normally and our state is…

But it looks like some other issue with FL.

And still I am more interested of calling AudioProcessorEditor constructor double times.

What is also worth to mention that each time my plugin is launched first time it takes quite long time (about 3-4 seconds). But after then even I remove all instances of my plugin and load again, then everything works fine. I am not sure how to debug it to find what operations takes so much time on first launch.

[pajczur]

OK, I’ve found out such behaviour is only on Windows Juce AudioPluginHost.
On OSX Juce AudioPluginHost and in other hosts like Logic Pro X or Reaper everything is fine.

[stephenk]

It is quite normal for various hosts to create and then destroy the editor several times while loading it. Your code needs to be able to handle it.

[pajczur]

@PeterRoos

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

Sorry, but what do you mean? I am the author of the post and I didn’t withdraw it. Shoul I withdraw it? Or what? And if yes, why I should withdraw it?

[pajczur]

@stephenk

Your code needs to be able to handle it.

Hello, thanks for your information. But could you give any advice me how to handle it?

Should I make any int counter; or anything like that? And dependently on host where plugin is launched (for example JUCE AudioPluginHost) should I prevent creating editor until counter reach the desired num?

Or is there any other, more elegant solution for that issue? Maybe in JUCE library there is such solution?

It is first time I meet such issue.

[PeterRoos]

No no, I withdrew my comment…

I was going to say that I had the same with Reaper (editor created twice), but you also mentioned Reaper and I did not want to confuse you.

Cheers

[pajczur]

@PeterRoos

I was going to say that I had the same with Reaper (editor created twice), but you also mentioned Reaper and I did not want to confuse you.

Acha ha ha,
Thanks.

But maybe could you share the solution you found for that issue for Reaper? Maybe it would also help in my case?

[PeterRoos]

No, I really can’t remember, this was many years ago. If you follow the correct guidelines for creating a processor that can create its editor when needed, it should be fine.

You really must remember that the processor and its state = your plugin.
When asked by the host, it must create an editor.
A lot of people have the incorrect mindset that the editor is “always there”. It is not.

Success!

[stephenk]

A “search” can be your friend:

PluginProcessor constructor is called twice by audio plugin host

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.

When (and how often) is the AudioProcessorEditor constructor called?

Is the AudioProcessorEditor constructor called just once (or twice, as I’ve read), when the host loads the plugin for the first time, or is it called every time you open the (already loaded) plugin’s GUI? Thanks

PluginEditor construction happens twice

Don’t mean to resurrect an old thread, but I’ve noticed this issue a few times and was always curious as to why it happened. The issue it caused for me was, when displaying a nag screen in the constructor of the pluginEditor, the user would have to dismiss it twice, as the constructor is called twice. Any good work arounds for this? I want it to be a nag screen to purchase, but I don’t want them to have to click twice.

…there are more.

[pajczur]

Don’t actually do anything time consuming in the constructor. (Start doing it later instead.)

But what do you mean by “anything time consuming”? I set in constructor all components bounds, all slider/button listeners, use for all components addAndMakeVisible, etc. And there are hundreds lines (of course they are ordered in appropriate methods).
I don’t have too much experience, but in my opinion it’s a lot of things to do. But is it time consuming? I am not sure.

And what do you mean by “Start doing it later instead”?
Should I run any timer that would wait longer than 2 seconds or something like that? And than run all components configurations?

[xenakios]

@pajczur

And there are hundreds lines (of course they are ordered in appropriate methods).
I don’t have too much experience, but in my opinion it’s a lot of things to do. But is it time consuming? I am not sure.

If you don’t actually know if it’s a problem or not, why do you even care if the multiple editor construction is happening?

It’s quite subjective what is “time consuming” but if getting the GUI constructed/destructed takes something like 1 second, that would be quite slow.

You can use the Juce Time class and its getMillisecondCounterHiRes static method to measure how long a piece of code takes to execute.

double t0 = Time::getMillisecondCounterHiRes();
// potentially slow code...
double t1 = Time::getMillisecondCounterHiRes();
Logger::writeToLog("Code took "+String(t1-t0)+" milliseconds to execute");

Or better yet, you could profile the code with the proper tools to see where the slowdowns actually are. They might not even be related to the construction of the AudioProcessorEditor.

[pajczur]

You can use the Juce Time class and its getMillisecondCounterHiRes static method to measure how long a piece of code takes to execute.

double t0 = Time::getMillisecondCounterHiRes();
// potentially slow code...
double t1 = Time::getMillisecondCounterHiRes();
Logger::writeToLog("Code took "+String(t1-t0)+" milliseconds to execute");

Hey great thanks for suggestion. My result is:
Code took 26.369 milliseconds to execute

So comparing it to one second seems to be nice.

I checked it like that:

AudioProcessorEditor* MyAudioProcessor::createEditor()
{
    double t0 = Time::getMillisecondCounterHiRes();

    AudioProcessorEditor* myEditor = new MyAudioProcessorEditor(*this);

    double t1 = Time::getMillisecondCounterHiRes();
    Logger::writeToLog("Code took "+String(t1-t0)+" milliseconds to execute");

	return myEditor ;
}

And I’ve made the same inside of AudioProcessor* JUCE_CALLTYPE createPluginFilter()
Here the result was about 12 milliseconds.

So do you think this issue is not worth to take care?

[xenakios]

The problem doesn’t appear to be in the AudioProcessorEditor constructor then. (Or in the constructor of your AudioProcessor either.)

But you are still getting slowdowns in the Juce AudioPluginHost when first instantiating the plugin? Are you sure it’s the plugin causing the slowdown and not just the AudioPluginHost being slow itself to start up or something? Starting up the debugger in Visual Studio can also be a bit slow. And if you edited your code, the code of course has to be built first before it can be run. That can easily take several seconds before the AudioPluginHost is even started.

[pajczur]

I am sure it happens in Juce AudioPluginHost only when my plugin is loaded.
Because when I remove my plugin from host, and save it, then relaunching Juce AudioPluginHost works normal (I mean much faster).

I also noticed that it is little bit faster when I compile my plugin in Release mode. But it’s really about 1 second faster or something about. But it still takes about 2 or 3 seconds. While with other plugins (and without my plugin) launching Juce AudioPluginHost is very fast ( I mean less than half second).

[xenakios]

OK, then it’s bit of a mystery. Might be a good idea to profile the code to see what functions are using so much time in the plugin code. On the other hand, it’s worth noting the Juce AudioPluginHost itself might still have some problem, it hasn’t been actively developed much in the recent years. If your plugin is working fine in other hosts, maybe it’s not worth it looking much into the performance problems just in the AudioPluginHost. (Unless you want to use that host for testing and debugging during development…)

[pajczur]

OK, but I made profiling only on OSX. Here the problem is only on Windows Juce AudioPluginHost.
Could you recommend any good tool on Windows for profiling audio plugins code?

(Sorry for question, there are for sure planty topics in google, but I am just asking for some recomendation here, where to start).

[xenakios]

Visual Studio, even the free Community edition, has profiling built-in. (Note that you have to build your plugin in release mode with debug symbols enabled, otherwise the profiler won’t be able to show you the actual function names.)

[pajczur]

OK, great thanks for your help. When I finish my investigation I will inform here what was wrong.

[pajczur]

OK, I’ve just made some quick profiling test with Performance Profiler. I am not perfectly sure if I made properly the tests. But it looks like the most consuming thing is with juce::WindowsTypeface

I am preparing in global scope thing like:
const Font myFont = Font(Typeface::createSystemTypefaceFor(myFont_ttf, myFont_ttfSize ));

I thought it is good practice to create such const Font to be able to use it later in various parts of code.

And I have there planty fonts (I mean about 50 lines like I showed above).

Of course I don’t need all of them in my plugin. But this is some global file which I also use in other projects.

Have you got any advice in that case?

[pajczur]

Now I am sure it’s Typeface::createSystemTypefaceFor that consumes most of time when launching.
I removed all instances of:
const Font myFont = Font(Typeface::createSystemTypefaceFor(myFont_ttf, myFont_ttfSize ));

and left only the one I need for my plugin, and now Juce AudioPluginHost launching time is very short.

By the way I still don’t understand why creating simply fonts consumes so much time. It seems to be something most obvious and optimized thing in computer. Doesn’t it? Steve Jobs was working with nice font typefaces on first Macintosh about 40 years ago. So how it is possible today computer need so much time to construct font from ttf file?

Thanks for all your help.