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

Problem with running the samples

Topics: Build, Getting Started, Newbie, VST.NET Core
Nov 21, 2013 at 11:16 AM
Hey everybody

We have been trying to start one of the samples so we can get to work with VST.NET it seems like a really good framework but we are having issues to get it working.

We are trying to run the CorePlugin sample, we followed the whole readme (running it with WPF) and we managed to solve most of the things, now when building we get only 3 warnings left and 1 error. The warnings are related to the DLL libraries saying:

Warning 3 There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "Jacobi.Vst.Interop", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project. Jacobi.Vst.Samples.CorePlugin

I guess that might be okay, but the error we get is really bugging us and we cannot find a solution for that:

Error 4 Source file '............_AssemblyInfo\AssemblyInfo.General.cs' could not be found C:\Users\georgi\Desktop\vstnet-74059\Source\Samples\Jacobi.Vst.Samples.CorePlugin\CSC Jacobi.Vst.Samples.CorePlugin

Could you help us please?? Thank you !
Nov 21, 2013 at 12:02 PM
There are some files (this include the keygen file referenced in the project settings) that are not checked in into codeplex on purpose. These files identify an official VST.NET release. These files can be safely removed from the projects. See also for more info.

Not sure about the warning - never seen it before - but it seems to indicate that you are mixing target CPU's between the VST.NET dlls and the sample project...

Hope it helps,
Nov 21, 2013 at 3:37 PM
Is it necessary (possible?) to set the build target configuration to 64 bit?

Setting the build configuration of all projects to 32 bit should fix it.
Nov 22, 2013 at 2:26 PM
obiwanjacobi wrote:
There are some files (this include the keygen file referenced in the project settings) that are not checked in into codeplex on purpose. These files identify an official VST.NET release. These files can be safely removed from the projects. See also for more info.

Not sure about the warning - never seen it before - but it seems to indicate that you are mixing target CPU's between the VST.NET dlls and the sample project...

Hope it helps,
I was going through that "Building the source" but it is confusing. I guess I am talking about this part:

"All projects (except the TestPlugin projects) use a private key file for signing the assemblies. Jacobi.snk is that key file and is NOT checked into source control. It is private to me and a way for users to identify an official release (important for the LGPL license). Also the projects use AssemblyInfo.General.cs/cpp which is also private to me.
These files are 6 levels up the folder hierarchy (relative to the project file) in my build. You either have to create your own files at that same spot with the same names or you have to change the paths in the project files to point to your private files -or- remove them alltogether."

How can I solve this? Create my own files, I tried creating an empty file with the same name but didn't really solve anything (maybe I didnt put it in the right place?") ... Is it that I have to buy something for this so called official release??
Nov 22, 2013 at 2:29 PM
obiwanjacobi wrote:
These files can be safely removed from the projects.
What's confusing?
Nov 22, 2013 at 4:38 PM
If the compiler is complaining about a missing file, remove the missing file reference in the project, for C# it will display a yellow triangle icon for the file. For C++ the file reference is in the project properties.
Nov 25, 2013 at 1:16 PM
Hey guys

We managed to build the CorePlugin sample but the thing is that we cannot actually start it and see how it works. We get the DLL output but cannot put it into the DAW saying Unknown error. ... Any suggestions? Maybe we could get it running separately from a DAW?
Nov 25, 2013 at 1:21 PM
What is the exact error (with stack trace?) ?
What DAW are you using?

Can you test any of the other sample plugins in the DAW?

One of the common errors is that the Jacobi.Vst.* assemblies can not be found during loading of the plugin. Make sure you have them in the same folder as the plugin itself.

You cannot test a VST plugin outside the a VST host (DAW). You CAN use a different host though...

Hope it helps.
Nov 25, 2013 at 2:26 PM
Edited Nov 25, 2013 at 2:28 PM
The error we got from FL Studio 11 says just "Unknown error" - we also tried with Ableton Live 9 and we can't even see the VST in the folder. We have put the other Jacobi.Vst DLL's in the same folder, but nothing happens.

We haven't tried with the other samples, we don't even build them, do you think that could be the issue?

Also, how about making the VST to be stand-alone, as some others are? Is that possible?

Nov 25, 2013 at 2:32 PM
I have not touched the Core Plugin for some time. I know the other plugins should work. So perhaps you could build the delay plugin and use that for testing.
BTW: Why do you use the Core Plugin - don't you want the plugin Framework VST.NET provides?

Open the VST.NET solution in Visual Studio and try to attach to the DAW and load the plugin. The debugger should break when the problem occurs and perhaps you can get additional information.

we'll get there....
Nov 25, 2013 at 3:00 PM
We have also built the Delay and the MidiSampler but we get the same unknown errors ...

I didn't get that part about the debugger - how can we have that if we are just loading the DLL into the DAW??
Nov 25, 2013 at 3:05 PM
Please note that we have removed the post-build events since they were causing errors. Could that be the issue?
Nov 25, 2013 at 3:12 PM
No, but then you have to make sure that:
  • You rename the plugin assembly from .dll to .net.vstdll
  • You (copy and) rename the Jacobi.Vst.Interop.dll to [MyPluginName].dll <- this is the file you want to open in the DAW.
  • Make sure the Jacobi.Vst.Core.dll is present in the same folder.
You can attach Visual Studio to any running process. Go to the Debug menu and select the "Attach to Process..." option. If you load (or rescan) the plugin the debugger should break when an exception occurs.
Nov 25, 2013 at 3:23 PM
Edited Nov 25, 2013 at 3:24 PM
Okay we did what you said and now FL Studio is saying this:

"The program can't start because MSVCR100.dll is missing from your computer. Try reinstalling the program to fix this problem."
Nov 25, 2013 at 3:33 PM
Because the VST.NET interop is made in C++ you need to install the Visual C++ Runtime Library.

Select the version that matches the VST.NET assemblies you have used (CLR2:VS2008, CLR4:VS2010 / x86,x64).
Nov 25, 2013 at 3:33 PM
Edited Nov 25, 2013 at 3:34 PM
You are missing Visual Studio 2010 Visual C++ runtime redistributable library on your machine.
Edit: got beat to it by Mark ;)
Nov 25, 2013 at 3:44 PM
Thank you Yury, appriciate it very much. Don't be discouraged ;-)
Nov 26, 2013 at 10:13 AM
Hey guys thanks a lot for your help! It's worked and all is good!

I would like to ask you, hopefully for the lasttime, for a little bit of guidance. We are planning to create a VST which uses a neuroheadset to read data from a human's brain and then use that to synthesize sound. We already have the headset going and can use it to get the data, what is left is to get the VST to do what it is supposed to.

Maybe you could help with that? We were thinking to work on one of the samples, as it would be too hard to start writing from scratch (and we don't have that much time anyway), the Delay sample looks suitable but what do you suggest we should study and use in order to have sound synthesized? Thanks!
Nov 26, 2013 at 3:21 PM
A 'normal' synthesizer accepts MIDI input and generates an audio output that represents the input. As I understand it your input is going to be a human brain (excellent idea btw!) and generate audio output based on that.

There is no sample that synthesizes sound but perhaps this will help: and

The Delay sample you plan to use, uses the VST.NET Plugin Framework. The Core Plugin Sample you used to get things working does NOT use this framework. For most using the Framework simplifies the plugin implementation quite a bit. If you don't want to take the extra dll overhead you can choose not to use it, but that also means that you cannot use the Delay sample plugin as a basis. You have to know a lot more detail on the VST plugin-host interaction if you do not use the Framework.

Note that there are also Visual Studio project templates that will give you a working Audio (or Midi) plugin on the Visual Studio Gallery (or in the Support folder in the Source Code tab).

Hope it helps,

PS: please start a new discussion if you have other questions.
Nov 26, 2013 at 8:59 PM
Maybe you need to think more about what you want/can achieve instead of how, some important questions:
  1. Does the neuroheadset apparatus runs in realtime?
  2. Do you need to develop your own synthesizer?
  3. Do you need to develop your own midi host?
  4. How do you intend to use your input, paremeter mapping?
  5. Given the current state of technology, how would this be different than a pseudo-random number generator?
I second the idea to start another thread ;)