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

Plugin load issue in certain hosts

Topics: Build, Host Compatibility
Jan 18, 2016 at 1:08 PM
Hi All,

I'm having an issue using the plugin I've developed in certain hosts. I have been happily developing away and debugging in VSTHost. My plugin opens and works correctly and even generates some fairly cool effects (imo), which has led me to think that everything is rosey.

So I thought I'd try and open the plugin in my personal fave host, Cubase, however it doesn't open. Cubase blacklists the plugin (identified by a reference in a Cubase file VST2XBlacklist.xml) and refuses to even try and load it. I am at a bit of a loss as to why this is happening, and confused as it opens just fine in VSTHost. Does anyone have any suggestions as to what to attempt to do about this?

Just some background info on my plugin incase it helps.. It's using CLR4 and the UI is WPF. I have attempted to load the samples (e.g. Delay) into Cubase and they seem to be blacklisted too.

Any help sincerely appreciated!

Many thanks

Jan 18, 2016 at 1:41 PM
Could there be a mismatch between 32-bit and 64-bit? I would suggest you rebuild your project for the same platform you have Cubase running.
Note, this is independent of the OS.

Jan 18, 2016 at 8:54 PM
I'm afraid that doesn't seem to be the problem... I've built the plugin as x86, x64 and AnyCPU. Cubase blacklists the DLLs every time. I'm running 64-bit Cubase so would expect x64 to work.

During build, I am copying the interop dll to the name of my plugin and renaming the plugin assembly to .net.vstdll (as per the samples), then copying both of these along with the core and framework DLLs - are there any other steps than this? I'm then copying these 4 files to the Cubase VST Plugins directory, and upon load of Cubase all 4 files get blacklisted.

I've tried to add all of the sample plugins too, and the same happens.

Many thanks for your help.
Jan 19, 2016 at 6:07 AM
The (renamed) Interop.dll determines if the plugin is 32 or 64 bit. So which one did you use?
Jan 19, 2016 at 7:28 AM
I've tried both x64 and x86 interoperability files, changing the target platform in my project settings each time.

Interestingly, v1.0 x86/CLR4 seems to work (the plugin opens in cubase) but v1.1 x86 does not. As mentioned cubase is 64 but so I would expect the x64 assemblies to work.

However, v1.0 x86 build loaded into audacity crashes the host. Not sure what I'm missing here, but nothing seems stable. All hosts are running on windows 10 if that makes any difference?
Jan 20, 2016 at 8:07 AM

So after lots of different attempts, the only interop file I can get cubase to recognise is v1.0 clr4 x86. All others are simply ignored. Even with this one working file, the plugin is wildly unstable and eats up 16% of the CPU when opened.

I'm at a bit of a loss now, as I've invested a lot of time into using this framework and it looks like the only option is get familiar with the c++ SDK.

Does anyone have any positive experiences of using vst.nwt to develop a plugin that works across a variety of hosts? I don't believe it is down to my code as I've followed the samples to letter.

Jan 20, 2016 at 8:25 AM
Any chance you could try on a couple of other hosts? VSTHost is particularly easy while Cubase is particularly picky, although I never heard this level of pickyness before...
If its not just Cubase - we may have a problem. If its just Cubase I could ask around on their dev-list. I do not own Cubase so...
Jan 20, 2016 at 8:19 PM
I've just tried it in Audacity. The audio processing seems to work but the UI controls (WPF) do not alter the parameters. I also got a message saying the plugin name was too long - I shortened it and created a new build but didn't get this error in Cubase.

Just some more info of what I've experienced in Cubase 7.5. So I've tried with every interop file from v1.0 and v1.1 - CLR4/CLR2/x86/x64. The only one Cubase will recognise is v1.0 CLR4 x86. When I load the plugin CPU usage jumps from 2% to 16% on a fairly good spec pc (core i7 4790k).

Interestingly the CPU drops quite a bit when audio is played through the plugin.

I've tried a build where no PluginEditor is created, but CPU usage still jumps up to 12/13%.

Bypass doesn't seem to work at all.

Hope some of the info is useful, many thanks for the support.

Jan 21, 2016 at 1:53 AM
Does anyone have any positive experiences of using vst.nwt to develop a plugin that works across a variety of hosts? I don't believe it is down to my code as I've followed the samples to letter.
  • Besides the DLL loader I haven't experienced the problems you described. I doubt such dramatic performance issues comes from the Vst.Net framework because it is a thin wrapper. I got around 0-2% CPU usage on a crappy Celeron dual core laptop. My advice is to attach a profiler to the plugin during execution to narrow down the offending bottleneck.