This project has moved and is read-only. For the latest updates, please go here.

Shared AppDomain Across Multiple VST Instances?

Aug 3, 2015 at 9:38 AM
The way pretty much all VSTs that I know about work is that they are completely separate application compartments in and of themselves. Today, I realised that when I load up 2 instances of my VST in ableton, they are actually sharing static variables.

I tried this code:
        private static int Test;

        public MySynthPluginStub()
On the loading of the second instance, the number was 2. That means that both instances on my VST share the same static variables, and I guess therefore the same AppDomain.

Is this reasoning correct?

Is this by design? I just find that in what I'm doing, a lot of variables need to be passed around, and I'd much prefer them to be static for easy access rather than passing them around through each class.
Aug 3, 2015 at 11:00 AM
The host determines how and if plugins are isolated. Typically most common Hosts will run all plugins in the same process (unmanaged), expect for specific remoting scenarios where the audio processing is done on a separate machine than the UI of the plugin is running on - not a very common scenario. So VST plugins are NOT separate compartments in and of itself!

So a static var is global within the process and that also means across all instances of that plugin. I would not recommend using separated AppDomains (in a managed Host and certainly not in a managed Plugin) because the coding will become a lot more complex as well as introducing a substantial marshaling performance overhead.

I would recommend you create a Data Transfer Object (DTO) for all your 'static vars' and pass only the reference to the DTO around. I would not recommend ANY statics in your Plugin (and as few as possible for the Host)...

Aug 3, 2015 at 12:04 PM
Thanks Marc!
Aug 3, 2015 at 12:24 PM
Edited Aug 3, 2015 at 12:48 PM
That really helped me to get over a hump!

Also, I can see this as a major advantage because the first time a plugin is loaded it can load all the necessary stuff, but it will never need to load that stuff again. It can share stuff across plugins. That will save a lot of CPU and memory.

Well, to put it another way, it's already made my shit load a lot quicker on the second instance!

Another win!
Aug 3, 2015 at 12:41 PM
When this method is called:
public VstPluginInfo GetPluginInfo(IVstHostCommandStub stub)
Will every single plugin that is loaded in the process share this same variable? I've called it stub.
Aug 3, 2015 at 1:17 PM
For a managed plugin in an unmanaged host the instance will be provided by VST.NET.
For a managed plugin in a managed host - it is the exact same instance you pass into the (Host)VstPluginContext.Create method.
As a host you can decide if you will reuse one instance for all plugins or give each plugin (instance) its own instance.

I envisioned you would, as a Host dev, create a custom PluginContext class for maintaining all plugin specific state (where it is in the chain etc) and mapping of host functions available to the plugin and therefor implement that interface on that PluginContext class as well and each Plugin instance would get its own instance...