Audio plugin demo


I’ve noticed that the following code get’s called 3 times when I load and open the fresh compiled
Demo plugin into juce plugin host:

AudioProcessorEditor* DemoJuceFilter::createEditor()
    return new DemoEditorComponent (this);

First time it gets called when I load the plugin, 2nd and 3rd time when I open the plugin.
Is this normal and if yes, why? That would create and destroy the DemoEditorComponent 3 times.
Makes no sense to me…


it’s normal.

For some hosts, it needs to report the size of the UI before it gets asked to actually put one on-screen - to do that it needs to create an editor and see what size it is.

But it’s not a big deal, don’t worry about it.


Thank you for your input!

But it brings me to another question. I want to initialize the plugin
from a binary blob. Inside Filter::setStateInformation is a sendMessage to
all registered ChangeListener but this messages never arrives because
the PluginEditorComponent isn’t existing as this moment.
It only works if I move the

setContentComponent (filter->createEditorIfNeeded(), true, true);

inside StandaloneFilterWindow before the setStateInformation command.
(I also have a Standalone version of the plugin!)
But actually I shouldn’t change that file as well as the VST_wrapper file, should I?

I am talking about the juce demo plugin. There is no own code involved!

Thank you again,


If your editor doesn’t yet exist, then why would it need to get a change message? When it’s created, after your plugin has loaded, it can just update itself then, right?


I am talking about the juce demo plugin not about my own code!
Why have you put the sendmessage command into setStateInformation if there is no need for?
The reason for all this is just to find out the best place where to place my initGUI methode (now I am talking about
my own plugin) to update the GUI from the binay blob.

The questions is just about who is the initiator for GUI update?
Should the filter call some GUI methods to update their components by passing the vallues or should the
GUI ask the filter for those values when it get’s constructed?
I don’t want to go the wrong way here…

Ah, I see, I mis-read your post. I actually re-wrote the demo plugin yesterday, so maybe check that out, (it no longer uses a changebroadcaster).

There’s no hard-and-fast rule about how to do it, it depends entirely on what the data is, and on the relationship between your UI and model, so I’m not sure what advice I could usefully give here.

Okay, thank you Jules.

I’ll check out the new plugin code.


As you mentioned the juce plugin demo no longer uses a changebroadcaster. It now seems to use a simple timer callback. Should this be the preferred method of updating the plugin editor? I’m not sure how one may be better than the other apart from in terms of simplicity.

I got rid of the changebroadcaster because that needs to dispatch an OS message, which isn’t a good thing to do on the audio thread. Using a timer is a really simple way to do it, some people use more complicated methods involving non-blocking fifos, threads, WaitableEvents, etc.

That’s good enough for me, a timer will do fine!