Closing an audio plugin

Hi, I’m currently building an audio plugin and was wondering if JUCE provides some callback or equivalent that let’s me add some code to (for example) alert the user before they close, and/or shut down running processes before actually closing the plugin.

Thank you

Not sure if thats already obvious for you, but the destructor is the place to handle cleanup work. However, starting some dialogue from there could probably be a bad idea. What‘s also not completely clear to me is what you mean by close, do you want your things to happen when the editor is closed or when the plugin instance is removed from a track?

Thank you for your response PluginPenguin. The destructor did not execute the dialogue correctly as you guessed. I would actually like to be able to handle both cases (when editor is closed and when plugin instance is removed).

modal dialogs are pretty bad. you don’t want them in your plugin. the better solution is to just add a component that’s kinda translucent that sits on top of your entire GUI showing whatever message you need to show to the user. There are lots of forum posts about how to do this, so search diligently and thoroughly!

Be aware that a host can destroy and create instances of your plugin at any point in time. Design your plugin accordingly.

For example, Final Cut Pro X doesn’t use the instance of your plugin that is attached to a clip when the playhead is manually moved around (and ‘audio skimming’ is enabled, which is enabled by default). Instead it creates and destroys multiple instances of your plugin every second and provides each instance a small audio snippet to create an audible preview of the current playhead position.

1 Like

Thanks for the suggestions! I’m still not totally sure about how I handle such events. Is there no specific callback for when the plugin editor is closed? or when the plugin instance is removed entirely?

There is no such callback, since it would be a bad user experience. In a project you easily end up with 10-20 instances of the same plugin. Do you really want your plugin to pester the user with 20 popups, if you are ok to close the plugin, even the plugin is not responsible for anything?
The saving the state is done from the host, the turning processing on or off is done from the host… everything. It is designed, that the necessary interaction with the plugin happens in the editor.
If you just want to capture analytics, that’s fine to do in the destructor. But user interaction during shutdown is a bad idea. (Again, the only valid exception is a save dialog, which is done by the host).

It should also be noted that not every host deletes your editor when you close the plugin window… some will hide the window and just keep your editor the background. In these cases your editor’s destructor won’t be called until the host is closed.

1 Like

Also worth noting with VST2, some hosts go through an open -> close -> open cycle with your editor when first instantiating the plugin, only actually showing the window on the 2nd open, so don’t try and do things where you expect there to be a GUI showing, because sometimes there isn’t!

Didn’t even know about this one… Ah, the joys of plugin development :upside_down_face: