Unload Plug-In from vst~

    Jul 15 2019 | 12:17 pm
    I've read on this forum that sending a bogus plug message (e.g. plug none, plug "no plugin", etc..) will clear the currently loaded plugin from the vst~ object. However this functionality seems to not be present in Max 8.0.6. For example, I do the following: 1. (plug) message to [vst~], pick a vst plugin 2. (open) message to [vst~], see plugin has loaded 3. close plugin window. 4. (plug none) message to [vst~] 5. (open) message to [vst~], plugin is still loaded.
    Is there anyway to unload a vst plugin from vst~?
    Many thanks for any help.

    • Aug 11 2019 | 9:35 pm
      I have the same problem (Max 8.08) -- sending a bogus plug message no longer clears [vst~]. Is there any solution to this problem?
    • Aug 13 2019 | 5:59 am
      1. use something like mda delay as your personal default plug-in and load this instead of nothing - maybe rename it to "bogus" :) 2. or script-recreate the vst object / reload it in a bpatcher patcher.
    • Aug 23 2019 | 3:10 am
      Option 2 sounds like it might for me - I will try it.
      Of course, it would be most convenient if there were a special message that could be sent to vst~ to tell it to unload a plugin -- it seems odd that there has never been such a command (or maybe it's just not been documented). I guess I should put in a feature request to C74.
    • Aug 24 2019 | 9:25 pm
      i havent tried it: what happens when you do "plug bogus" while having the patch to a ":bogus.vst" actually in your search path? (which is a text file and will fail to load)
    • Aug 25 2019 | 12:07 pm
      I've tried with "plug MaxBogus.component" (text file in the Component folder) and it just throws an error message and opens the currently loaded plugin.
      Since we cannot unload a plugin, I just bypass it (message "bypass 1") and close the window (message "wclose"). It is still here, but idle. "bypass 0" is sent when a new plugin is loaded. If you are scared about memory or CPU, you can automatically load a tiny plugin for the idle time.
      Additionally, when working with my own GUI, I deactivate, hide or cover clickable elements that work with [vst~], so they can only be used after loading a new plugin. An unload command is definitely missing.
    • Aug 25 2019 | 12:24 pm
      The trouble with the load-a-minimal-plugin workaround is that this is not suitable when building standalones for general use. So, yes, a working unload type of command is essential for that scenario.
    • Aug 25 2019 | 12:36 pm
      I don't know about Windows. On Mac you can always load something like AUParametricEQ which exists on all Macs. It has a neutral default setting, but you want to bypass it anyway.
    • Aug 25 2019 | 12:45 pm
      Thanks, that's useful to know.
    • Aug 25 2019 | 2:12 pm
      yes, on mac the systemwide folders for AU/VST/MAS/protools are always in the search path (or to be exact: default VST/AU folder) for max. on windows it is more complicated. and even on mac it is an issue, because it would only work when you include that in your installer. and maybe you dot not want to make an installer...
    • Jan 18 2020 | 10:49 pm
      The best solution I have found for this (it will work for standalones on Mac and Windows) is to use a script to [thispatcher] to delete the vst~ object whenever "no plugin" is chosen by the user, then immediately instantiate a fresh vst~ and its connections. The new [vst~] is, of course, empty as desired. If using presets, it is also necessary to clear the associated dictionary saved for the old vst~. This can be done by saving a 0 with a message like "setstoredvalue my_vst n 0" sent to [pattrstorage] where n is the preset number.
    • Jan 18 2020 | 11:45 pm
      ...which is only a good solution when your vst object is not in a custom vst abstraction, like in my case. i actually wonder how default is loaded when you send "plug" in max v4. is default built into the external? i shall dissemble this thing.
    • Feb 01 2021 | 10:51 am
      Option 2 works great! Thanks y'all! vst~ purged!
    • Feb 01 2021 | 11:10 pm
      nobody ever had the idea to write a max external that hosts a vst~ object providing advanced funtionality like a unload or a "ShowShellDllPluginChooserDialog" method? These two things i wanna do next. (But i can not tell when this will be ;)
      i also allready suggested these 2 extensions to the cycling team as a native support by vst~ but i'm not sure they got what i meant, (i was fighting with a bug in this conversation and it was not my prior issue.)
      maybe it reaches someone who wants to do it this way, @PETER OSTRY ?
    • Feb 02 2021 | 12:41 am
      "plug xxx" worked well to unload the current plug-in from vst~ in the good old times. today you could use a dummy plug-in. or mda delay. or the gain example from the vst sdk. or, if you dont mind interrupting DSP, re-script the VST object