Problem loading sample dll's in Cubase

Dec 10, 2009 at 9:06 AM
Edited Dec 10, 2009 at 9:42 AM


Absolute newbee, trying to get a feel for the VST.NET library by setting up the sourceprojects, looking through the samples and trying to get the meaning of it all.

I Think that I now understand the relation between the host (in my case Cubase), the (renamed) interop and the plugin itself. As I understand it, the interop is a decoupling of the lowlevel connectivity with the host, so that the host "sees" this as the plugin, never knowing that it is just a "facade" to the plugin. (correct me if I'm wrong).

Everything compiles nicely and I have made the sugested post-compile scripts, renaming/copying the interop to a folder along with individual plugin assemblies. So far so good.

To get an idea about the implementation of the plug-ins created using VST.NET I copied the newbuild (and renamed) .dlls (specifically Jacobi.Vst.Samples.Delay.dll and to the vst-plugins dir of my host (Cubase SX3)

when starting up Cubase after this it "sees" the plugins, but never loads them. They stay in the "brown" group of unloaded plugs in the plugin-information dialog in Cubase and are inaccessible.

I am not really sure if it is correctly understood, but I guessed that the host.exe (in the samples) would be a simulation of a vst-host, alowing you to try to load the plugins in a "friendly environment", thus exploring the exposed parameters and so on. Having this idea, I tried to load them here, but never got that far. I got a stackoverflow error from within the vst.core (which I cannot debug) on the OpenPlugin method (host's mainform) when it tries to create the plugincontext for the plugin.

I tried (both in Cubase and the host.exe) with both my own compilation of the samples and with the allready compiled samples from the download, but with the exact same results.

What am I missing here ?

PS.: I have tried compilng, using both .NET 2, 3.5 and 4 but with the same results.




Dec 11, 2009 at 8:09 AM

Hi Niels,

You've got the Interop figured correctly. It is the facade that mimics an unmanaged VST plugin and delegates all the call to the managed plugin, which is loaded through the naming convention ([SameName].net.dll).

The stackoverflow in the Host sample is a bug in the Host.VstPluginContext (Interop). When you get the latest source code and build that, it should be solved. 

Cubase: You can try to rename the to end in extension .net.vstdll. This alternate extension was introduced for hosts that blindly load all .dll's in a certain directory. The ManagedPluginLoader also searches for the alternate extension when trying to load the managed plugin.

I don't think you're missing much. You seem to do everyrthing right. Its just that a new release of VST.NET is way due and I hope to get round to it at the end of this year ;-)

Except for the WPF option in the Jacobi.Vst.Samples.CorePlugin -which requires .NET 3.0 or higher- all code should work with .NET 2.0.


Another thing you could try is to download vsthost.exe -a free VST plugin host by Hermann Sieb- and try to load the managed plugins in that host. It is the host I test with.

Get back to me when you have no success in loading the sample plugins.

Dec 11, 2009 at 12:54 PM

Hi Obi

Thanx for reply

Tried your suggested solution, but no success I'm afraid.  

When renaming the plugin to, Cubase still recognizes the Jacobi.Vst.Samples.Delay.dll as a plugin, but can't load it - it still shows up in the group of not-loaded plugs in the plug-in information dialog. Only difference seems to be that it now does not consider the original pluin dll to be something to be loaded, which I guess is OK (it really should only load the renamed interop, not the managed plugin), but still even the interop (renamed) is not loaded, only put in the "not-loaded" group.

I tried loading into the vsthost.exe, as you suggest, but same result here. Nothing loads (to be sure I have loaded different plugins, which works - they all create this little box in the project-surface with midi-settings and so on for the loaded plug. This is not the plugs actual UI, but a part of VSTHOST itself. Therefor I expected this to show up for the delay as welle, even if it had no UI itself, but nothing shows up. I tried both loading from the assigned vst-plugins folder and from my VST.NET _sharedassemblies folder, but no difference here.

I have not GAC'ed the dll's as I always put them in the same folder (either the _sharedassemblies or the assigned vst-plugins folder). I guess this would be OK, or ?

Any more ideas ?


Dec 21, 2009 at 7:38 AM

Check out the new release 0.8. All samples except CorePlugin should now load in Cubase again.

Cubase relies on the effIdentify opcode to be implemented -and returning a very specefic value. When implementing the deprecated member support I moved that implementation from interop to the new StdPluginDeprecatedCommandStub class but forgot to let the samples use it.

I tested it with Cubase SX 2. If you have any problems let me know.

Dec 21, 2009 at 9:03 AM

Hi Obi

Same picture after downloading and building the VST.NET 0.8 samples. I tried using both the pre-compiled versions in the binaries folder and the binaries from my own build, but same result. However the plugins now load in your HOST.EXE, which did not happen before.

Perhaps I should note, that I use Cubase SX3

As I read your last post, I must confess, that I had some difficulty in understanding that the effIdentity was basis for my problems, as loading the plugins gave the same problem in the VSTHost program. The VST.NET 0.8 dll's has the same problem here as mentioned earlier about the VST.NET 0.7 dll's, so this probably is not (only) a problem with Cubase's VST implementation ?

As mentioned all other plugins, placed in the same folder (my assigned vstplugins folder - used by both Cubase and VSTHost) loads fine in both Cubase and VSTHost. I have tried removing and then replacing some of them, and everytime I load either Cubase or VSTHost, they reflect the chhanges and load the plugins flawlessly - all except the jacoby samples, that is.

If you are absolutely positive, that the dll's load in the latest version of VSTHost (as I understand, you use this host for testing),  I guess that this is the least common denominator and I will try to go through everything in my installation of this (getting latest version, reinstalling and so on) to see if I can get this to work. Maybe this will give some evidence as to what I do wrong when using Cubase.

Could you please confirm, that you are able to load them in VSTHost.



Dec 21, 2009 at 11:38 AM

Hmm, to my knowledge vsthost.exe does not call effIdentify but Cubase does. For me it was all that was needed to get the pluginto load as an insert. I just tried the Delay plugin and it loads (and works) fine in VstHost as well. Cubase will not load any plugins that does not respond to effIdentify with a very specific value.

Perhaps you could try the new tracing feature? Copy the app.config to the Cubase directory and rename it to cubase(sx).exe.config (the name of the exe and add the .config extension). Edit the file and replace the [PluginName] placeholders with Jacobi.Vst.Samples.Delay. Make sure the swicthes are on (All in the bottom section of the config). Now startup DebugView or attach a debugger to cubase and load the Delay sample. You should see all dispatch calls (and others) made to and from the plugin. Perhaps that will shed some light. Post the output so I can take a look at it.