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

Plugin failed to load

Topics: 64 bit, Build, Exception, Host Compatibility, Host Development, VST.NET Core, VST.NET Framework, VST.NET Interop
Sep 25, 2014 at 6:56 PM

i'm sorry that i'm asking so many questions but i just stumbled over a weird behaviour in my self written vst host and i can't figure out what's wrong.
In my c# which currently gets compiled to 32 bit has references to the CLR4 x86 VST.NET dlls. This setup worked fine for pretty much all plugins i opened in the host.
Now i downloaded Tone2's FireBird2 Synthesizer plugin and immediately tried it in Hermann Seib's VST Host. There it worked fine, no problem at all.
After that i tried to open it in my own Vst Host but got an Error when creating the VSTPluginContext object for it saying "....\FireBird.dll" failed to load. (Well at first it said MissingResourceManifestException but then i downloaded the 1.1 version of VST.Net)
My first guess was that maybe it is a 64 bit plugin and can not be opened in a 32 bit host so i changed the References in my project to the x64 dlls and switched the build configuration of the project to x86. The result was that now no plugin would open. All of them give me failed to load even the FireBird.dll.

I'm guessing that you probably won't be able to directly point me towards the solution but i would like to know where i could look for the problem or what i could try.
Maybe i just did something wrong when changing to 64 bit. Can 32 bit plugins be opened in 64 bit and the other way around?

Sorry for answering so (probably) stupid questions but i just can't wrap my head around it.
Sep 26, 2014 at 3:57 AM
32 bits and 64 bits cannot be mixed, no exceptions but the any cpu setting is kind of an oddity of the DotNet framework.
Setting the solution build configuration is not enough, you need to edit the build configuration to ensure EVERY project in your solution is matching the solution configuration choosen.
You can't use x64 reference in a well configured x86 programs as you said you did, it will not link properly and crash with dynamic dll loading.
My guess is that your main project has an any cpu configuration in the x86/x64 solution build configuration.
Vst.Net rely on the native vst library, native doesn't support any cpu configuration, so make sure none of your project has this configuration.

Besides that I had the missing manifest error you mentionned when loading some plugins, it is an error in Vst.Net. It occurs when it tries to load it's resx file to display an error message to indicate that it couldn't load a plugin. It was a hard one to debug, I did find a workaround though. It doesn't occur on release build run outside Visual Studio. Also I try to load every plugin 2 times before declaring a fail, some plugins throw an exception the first time but loads on the second try, dunno why,
Sep 28, 2014 at 11:49 AM
Thank you Yury. That explains a lot.
Even though it says on the web that Firebird 2 comes with a x86 and a x64 vst it seems like I only have the 64 one.
Fortunately i found a workaround where i use the Legree plugin to integrate Hermann Seib's vst host as a slave of the plugin and then host Firbird inside the slave host. This seems to work but it doesn't seem like the best idea. I don't get any problem with it for now but i feel like performance might be an issue further down the line. Is there any other way to "wrap" a 64 bit plugin somehow so that i can host it in 32? Like a wrapper plugin or something?
If not i'm gonna stick to the slave host solution for now.
Sep 28, 2014 at 1:03 PM
Edited Sep 28, 2014 at 1:08 PM
The only way to do this would be through inter-process communication (IPC) since the two process architecture are incompatible. That means you have two vst host of different architecture communicating with each other.

Of all the methods available, shared memory is the only one I'd consider for real-time audio processing. Latency and stability are the main hurdles to overcome.
Sep 28, 2014 at 1:12 PM
Did a quick search on 'ipc vst' and jBridge popped up, seems to do what you want. I think IPC in real time systems is a kludge but it might work well enough for you.
Oct 6, 2014 at 9:05 PM
Sry for not posting in quite a while. I didn't had much time to work on this topic.
Thank you for the hint to JBridge. I will totally check it out if using the host slave is hitting my performance too hard.