We want to open a window in the constructor of our audioprocessor for a validation/activation process.
On OSX with Reaper/Logic/StudioOne/Live (AU or VST) … while the host scan our plugin, after we close our window (and the plugin is closed) the host either crash or fall in a loop.
The behavior is easy to reproduce with the JuceDemoPlugin.
For example by adding the following code at the end of the JuceDemoPluginAudioProcessor constructor:
Everything work fine if we replace this code by
Oh god no!! Please don’t try to do that. It’s bad on so many levels!
As a host-writer, plugins that attempt to run a modal loop are just a total facepalm - just imagine the horrible re-entrant stack calls that end up happening… And if a plugin goes re-entrant and is then closed, it’s impossible for the host to unwind the stack without crashing. It’s even impossible to detect it happening!
And now that hosts are starting to run plugins in child processes (or even remote machines!), modality is even more dangerous than it used to be.
What you can do is open a window, and put it into a modal state, but don’t run the modal loop yourself - e.g. use . If in doubt, you might want to set JUCE_MODAL_LOOPS_PERMITTED=0 for your project, which should prevent you doing anything silly.
…but even that will make people hate you! There’s nothing more annoying when scanning for plugins than the ones that pop up their irritating unlock windows every time… People who’ve installed your demo will see your plugin’s name popping up again and again in a nagging way, and will associate it with their annoyance in having to keep dismissing it - it’s not good marketing.
Why not just embed your unlocking window inside your plugin’s GUI? That’d be my approach to this kind of thing.
Well, it’s not a nag screen and the process make it so it will popup only once so we are not that much afraid of annoying our customer.
Anyway, we already took in consideration the idea of moving this popup to the first time the GUI will be open and there is a good chance we will do just that.
Still it seems there is a bug somewhere that impact the Juce Window in this context on OSX where NativeWindow are just fine.
No - honestly, there’s no safe way to run any kind of modal loop in a plugin. A native window might be able to use a few more tricks to avoid problems, but there’s no way it can be bulletproof. Some host in some situation is sure to mess up one day, no matter what you do.
You do understand the problem, right? i.e. having recursive event loops on the stack? It can lead to situations that just can’t be fixed or worked-around. This is why modal loops are so frowned-upon nowadays, and completely banned in some newer OSes, e.g. android.
Yes, I do understand the problem and as said before we start to change our process.
Just thought there might be a solution/improvement to make in the juce window for this behavior.
Thanks for your answers 