I am trying to design a managed library to implement -what appear to be- unmanaged VST3 plugins. The VST3 plugin interface is a C/C++ interface-based API that is compatible with COM (ref-counting, HRESULT etc.) - but is not COM (no reg, CLSID etc). The entry point into the plugin is an exported (on windows) function that retrieves a class factory (much like COM). From there its all COM-compatible interface-based communication.
I want to implement a Mono solution that works on Windows, Mac and if possible, Linux. I have found a description of how to embed the Mono CLR into your assembly together with C code and the managed IL code. http://www.mono-project.com/docs/advanced/embedding/ This looks like a way to get from C to the managed world with mono - although it feels like a heavy weight solution.
Then I want to use COM Interop (CCW/RCW) to do automatic marshaling of the VST3 interfaces. I have done a Windows/MS trail that sort of worked (problems are beyond this discussion & not portable), so if I could reuse that code, that would be awesome. Here is an example of the object factory: https://vstnet.codeplex.com/SourceControl/latest#Source3/Code/Jacobi.Vst3.Interop/IPluginFactory.cs
There are a couple of questions I have for this design I would like to have answered before I continue with the effort.
- Would this design (embed the CLR and COM Interop) work?
The embedding part I'm pretty confident in, but how about COM-Interop on Mac/Linux?
- How do function exports work on Mac and Linux?
The host application needs to be able to call into the plugin using this exported C function.
- Would I need to write specific code for each platform?
I would like to have only one code base with minimal special cases.