Add a deactivation callback

This is the equivalent of initialize()

plugins/examples/gain/src/lib.rs

@@ -145,6 +145,10 @@ impl Plugin for Gain {
 
         ProcessStatus::Normal
     }
+
+    // This can be used for cleaning up special resources like socket connections whenever the
+    // plugin is deactivated. Most plugins won't need to do anything here.
+    fn deactivate(&mut self) {}
 }
 
 impl ClapPlugin for Gain {

src/lib.rs

@@ -58,6 +58,9 @@
 //!      `Buffer` object for all of the ways you can use this API. You can access note events,
 //!      transport data, and more through the [`ProcessContext`][prelude::ProcessContext] that's
 //!      also passed to the process function.
+//!   6. [`Plugin::deactivate()`][prelude::Plugin::deactivate()] is called from the when the plugin
+//!      gets deactivated. You probably don't need to do anything here, but you could deallocate or
+//!      clean up resources here.
 //!
 //!  - Plugin parameters are managed automatically by creating a struct deriving the
 //!    [`Params`][prelude::Params] trait and returning a handle to it from the

src/plugin.rs

@@ -145,6 +145,16 @@ pub trait Plugin: Default + Send + Sync + 'static {
     /// TODO: Create an example plugin that uses block-based processing
     fn process(&mut self, buffer: &mut Buffer, context: &mut impl ProcessContext) -> ProcessStatus;
 
+    /// Called when the plugin is deactivated. The host will call
+    /// [`initialize()`][Self::initialize()] again before the plugin resumes processing audio. These
+    /// two functions will not be called when the host only temporarily stops processing audio. You
+    /// can clean up or deallocate resources here. In most cases you can safely ignore this.
+    ///
+    /// There is no one-to-one relationship between calls to `initialize()` and `deactivate()`.
+    /// `initialize()` may be called more than once before `deactivate()` is called, for instance
+    /// when restoring state while the plugin is still activate.
+    fn deactivate(&mut self) {}
+
     /// Convenience function provided to allocate memory for block-based smoothing for this plugin.
     /// Since this allocates memory, this should be called in [`initialize()`][Self::initialize()].
     /// If you are going to use [`Buffer::iter_blocks()`] and want to use parameter smoothing in

src/wrapper/clap/wrapper.rs

@@ -1575,8 +1575,11 @@ impl<P: ClapPlugin> Wrapper<P> {
         }
     }
 
-    unsafe extern "C" fn deactivate(_plugin: *const clap_plugin) {
+    unsafe extern "C" fn deactivate(plugin: *const clap_plugin) {
-        // We currently don't do anything here
+        check_null_ptr!((), plugin);
+        let wrapper = &*(plugin as *const Self);
+
+        wrapper.plugin.write().deactivate();
     }
 
     unsafe extern "C" fn start_processing(plugin: *const clap_plugin) -> bool {

src/wrapper/standalone/wrapper.rs

@@ -309,6 +309,10 @@ impl<P: Plugin, B: Backend> Wrapper<P, B> {
         terminate_audio_thread.store(true, Ordering::SeqCst);
         audio_thread.join().unwrap();
 
+        // Some plugins may use this to clean up resources. Should not be needed for the standalone
+        // application, but it seems like a good idea to stay consistent.
+        self.plugin.write().deactivate();
+
         Ok(())
     }
 

src/wrapper/vst3/wrapper.rs

@@ -373,7 +373,11 @@ impl<P: Vst3Plugin> IComponent for Wrapper<P> {
                 }
             }
             (true, None) => kResultFalse,
-            (false, _) => kResultOk,
+            (false, _) => {
+                self.inner.plugin.write().deactivate();
+
+                kResultOk
+            }
         }
     }