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

Do we need VST 3.x support?

Topics: Backward Compatibility, Cross Platform, Other
Nov 4, 2012 at 9:50 AM


I want to run this by you.

Do you think support for the new VST 3.x SDK is needed?

I also want to look into Mono and if we can make the new library portable over multiple platforms. At least Windows and Mac and perhaps Linux.

I have no experience working cross-platform or with Mono, so any help with that (tips, pointers, resources) would be most helpful.

I have read the newest VST 3.5.2 documentation and technically it should not be too hard to make something that works in .NET. The new SDK is interface based (at C++ level, which is totally different than VST 2.x) - but we're already used to that ;-)

If you have any other ideas on this subject please share them here. I would very much like this to be a community discussion - not a monologue on my part :-P

Nov 5, 2012 at 4:02 PM

I'm neutral on the VST 3 issue, though there's something to be said for keeping current (within reason).

However, I'm very much in favour of future cross-platform support!  I'm a a Windows (FL Studio) user myself, but many of my collaborators here in the music scene use Macs exclusively (probably a common situation) and I'd like for them to be able to use the VSTs I create.

Nov 5, 2012 at 9:41 PM

Thanx for your response.

It is too much work to try to fix the portability issue with the current version of VST.NET. But if I am going to build something for the new VST version that definitely has to work. That will mean working with Mono though. I'm already researching how to do portable C++ interop in Mono and it is possible, all I have to do is pick the best performing option.

Dec 1, 2012 at 2:38 PM
Edited Dec 1, 2012 at 8:47 PM

Vote on this issue here:

Dec 1, 2012 at 8:32 PM
Edited Dec 1, 2012 at 8:32 PM

VST 3 support is a top priority for me, 2.x is going to be deprecated someday. However I don't care about Unix system, it doesn't seem like a likely candidate for .Net project.

Dec 1, 2012 at 8:44 PM

Thank you for responding (and voting).

Linux is not a must have, but Mac is. And if you use Mono to get it to work on the Mac it will probably also work on Linux.

Jan 31, 2013 at 5:05 AM
That would be awesome if you could get this working on Mono!!
Jan 31, 2013 at 10:25 PM
Oh for me it'll be Mono all the way. For all of the DAW testing that I've done with Javelin I haven't once run into a VST 3 and I have quite a few plugins (all of the wasted on me). I'll definitely be needing that Mac version Marc so get cracking :)

Of course I haven't read the v3 white paper but that's my gut feel.

If you have an ancillary lifting or plebe work I'll gladly volunteer....
Feb 1, 2013 at 6:19 AM
Unfortunately VST.NET (2.x) as it is now cannot be ported - it uses the Microsoft specific C++ extension to do the marshaling between C++ and .NET.

So its VST3 (.NET) on mono only...
Oct 14, 2013 at 12:46 PM
I think I might have found a way to implement interop for VST 3.x in a simple way. If I get it to work it would mean that there would be an exact 1:1 translation of the C/C++ VST 3.x specs to .NET and it would work on Mac also. It would require the plugin to use Mono to work on non-windows platforms.

Have not looked into supporting the interop for managed hosts yet in this case, but it should be almost as easy.

Very exciting stuff. I have done a very simple test on windows which looked very promising.

I am working on a test application to test the concept and I am looking for people that can compile a simple C++ test app (source supplied by me) on the Mac and then run the app on the Mac, to see if that works. So if you know how to compile C++ code on the Mac and you are willing to spent a little time on this test, I would love to hear from you.

Oct 19, 2013 at 9:23 PM
I'm really looking forward to VST 3.0 but last time I've looked at mono it was only suitable for hello world type console projects.
Oct 19, 2013 at 10:08 PM
From what I have read, Mono has Com wrappers and a full P/Invoke implementation. I have good hopes for it actually working.

I am currently trying to build a VST 3(.5.2) test plugin in .NET that would work with the native VST3 test application that comes with the SDK download. Once I have something that works, I will ask people to test it on Mac with the Mono framework. For now progress is slow and each and every interop method takes several tries to get right. But I have made some headway today and hope to do some more tomorrow. At least I will end up with something that will work on Windows ;-).
Oct 19, 2013 at 11:44 PM
Edited Oct 19, 2013 at 11:53 PM
OK if this is what it takes I have a Unix (mac) box at my workplace ;-)

We are running XCode though and churning out iPullMyFinger type apps as a side job. I'm not sure when I'll be able to do mobile stuff again but I might be able to sneak install the GNU C++ Mono toolchain somewhere in the future if you don't have any volunteer. I don't think my wpf host can ever run on a Unix box but I'm really thankful of the work you are doing. I still have a few dependencies on Win32 to update (OpenCV, Midi.Net) but I'm looking toward 64 bit too mostly because of the read out of protected memory errors and the mess that is VST 2.x. Thanks again for the framework Mark.
Oct 20, 2013 at 8:47 AM
You're welcome.

You do have to think about the UI framework when going for a multi-platform / mono solution. WPF is MS specific - but mono has a WinForms port and other frameworks as well that may (not sure) run well on both Windows and Mac (and some even on Linux). Nice thing about VST3 is the processor - ui separation so even if you had to rewrite the UI for a specific platform - the processor code (DSP) can remain the same. For hosts, that is a different ballgame and you have to make sure you design that ui separation in yourself...

I will post a separate message when the time comes to find people who are willing to try it out. Thanx!
Nov 20, 2013 at 4:37 AM
I'll be happy to help you test when you're ready.

Damnit. I thought I was cool moving from WinForms to WPF...
Nov 20, 2013 at 7:31 AM
Excellent, thank you.

I am currently iron out some bugs. I have most of the interface definitions done - but only a small portion is tested yet.

Look in the Source3 folder in the source code to see the code, if you're interested.
Jul 7, 2014 at 4:38 PM
whats the current status of this?
Jul 8, 2014 at 7:09 AM
I have a considerable amount of code in the Source3 folder for VST3. The problem I ran into is the fact that the default apartment the CLR uses for COM calls uses a hidden Window to sync and queue calls (as window messages). This introduces a considerable overhead onto every single method call that is unacceptable for realtime audio processing. I could find no way to indicate free threading to CLR in order to be called directly.

There was also another issue with the tear-down sequence of COM object provided by the Host vs the plugin COM objects. Although not as fatal as the previous issue, I did not find a solution for this either.

So the project is stuck for now. I am planning on giving Mono a try in an attempt to fix this, but I have not come round to it yet...
Jul 8, 2014 at 5:44 PM
I'm a bit lost with your explanation, how is COM calls related to VST.Net 3.0?
Are VST.Net 3.0 plugins implemented as COM Object? If so how does mono would be more fit?
Jul 9, 2014 at 9:06 AM
No, VST 3.x does not rely on COM - this would make porting it to other OSes a problem. BUT, the VST 3.x interfaces are COM compatible. So I though I would use COM interop to make the jump from C++ to C# (and back). That is where I ran into problems.

Mono is available on Windows, Mac and Linux. So if I could get it to work with Mono, we would have a VST.NET (3.x) that works on all these OSes. The current VST.NET only works on Windows due to the way interop is implemented. Portability to other platforms was one of the 'issues' I would like to fix.
Jul 9, 2014 at 2:54 PM
OK that's more inline to what I thought. As I recall mono supports only a subset of DotNet and WindowsForms libraries. What mecanism could replace standard C++ Interop? And does that mean that compatibility with DotNet is dead?
Jul 9, 2014 at 6:52 PM
Edited Jul 9, 2014 at 6:53 PM
There are 2 major options for interop using Mono as far as I can see. First is COM interop which is currently only for Win and Mac and not Linux. This would work more or less the same as COM interop on dotNet. Not sure how rich the feature set is on Mono. The reverse-P/Invoke I used on windows (allows you to write managed functions that can be called from unmanaged apps) might also not work with Mono. Another option would be to write a C++ interop layer that needs to be portable to each platform. Not sure on the details on that. It will need more investigating.

It is true that Mono does not implement the full feature set of the dotNet base class library. But if you only target Windows you should be able to still use the dotNet technologies. If you target multiple platforms (say Win and Mac) you probably want to use something else to write your UI in, something that handles the differences in the OS look and feel for you a bit more.

Like I said, I really need to spent more time on Mono before I can make any further progress with VST.NET 3.x.
Jul 9, 2014 at 7:17 PM
Hopefully I don't bother you too much with my questions. Just trying to summarize everything.

Reverse-P/Invoke would work with VST 2.x/3.x and DotNet framework.

COM Interop with VST 3.x would work but has speed issues with DotNet framework because of the hidden window message pump workaround used in STA mode.
It's not possible to run COM Interop in a MTA thread and there's also the CoUninitialize screw up that would need to be taken care of.

Regarding mono viability of both reverse-P/Invoke and COM Interop is unknown and there isn't any other Mono only mecanism available to cross the managed/unmanaged barrier.

What I meaned was will a solution targeted for mono shortcomings still work with the DotNet stack (without mono). If I'm not mistaken, version 1.0 of mono wasn't compatible with DotNet, namespaces were different and necessary shims would break cross compilation of the same source on the two frameworks.

In my view Mono is still the limiting factor here, since reverse-P/invoke works with DotNet. However I have very limited/outdated knowledge of Mono and since this is a pretty complicated subject I'm probably not knowing/understanding something important here.
Jul 10, 2014 at 7:58 AM
From what I can see, Mono is pretty compatible with dotNet. Even when reversed P/Invoke and COM interop do not work in Mono, Mono still offers other options that are not available in dotNet and may well provide a solution (such as embedding). It just needs more research (time! ;-).