VST vs Rewire

[obiwanjacobi]

Hi

I'm looking into the different plugin standards to investigate the possibility to write one unifying "uber" API.

I know about VST and Rewire and I was wondering if there is any information how these two compare; both on features and code level. Are there any other plugin standards that are major players?

-or do you know if there already is such an uber API?

[asomers]

Huh??? ReWire is not a plugin standard. It's an IPC protocol with very specific features. You haven't heard of Audio Units (mac proprietary) and RTAS (digidesign) plugin standards? VST, Audio Units, and RTAS are the major players, I guess. JUCE is an API that wraps all of them. It's your "uper API". There's also Infinity, but I don't know if it does RTAS.

[jupiter8]

To do RTAS plugins you need to be approved by Digidesign first. So i doubt either of JUCE or Infinty does RTAS. Even if they have templates for it you still need Digidesigns approval for the actual SDK.

[asomers]

JUCE does RTAS but of course you need to obtain the SDK on your own. Same goes for VST, sans the hoop of fire.

[Architeuthis]

Please never use ReWire, I've had very bad experiences, it's a very clumsy interface/design. VST is infinitely easier to integrate with a sequencer.

[obiwanjacobi]

"Please never use ReWire, I've had very bad experiences, it's a very clumsy interface/design"

Well, this whole idea started because I think VST also has a very poorly designed SDK. I sketched some new structure for the main functionality for VST and then realized my new design could function as an abstraction layer and perhaps could incorporate other standards as well.

I will have a look at JUCE.

Thanx everyone.

[aciddose]

just write your code so that it exposes a generic interface which you can wrap with vst, au, dxi or whatever other interface you want. that way you wont need to write a complex "uber wrapper" since it'll only take a couple of minutes to re-wrap your generic interface in something else.

think of it like creating a whole factory with robots in order to change your coat automatically vs. just taking off your coat and putting on another. you're not going to do it a million times a day, so you dont need a bunch of robots.

[Jeff McClintock]

Hi

I'm looking into the different plugin standards to investigate the possibility to write one unifying "uber" API. Are there any other plugin standards that are major players?

-or do you know if there already is such an uber API?

GMPI was such an attempt. Not completed (officially), but the requirements docs make good reading as far as describing the theoretical state-of-the-art.

http://en.wikipedia.org/wiki/GMPI

Jeff

[obiwanjacobi]

I just looked at the JUCE documentation at http://www.rawmaterialsoftware.com/juce/api/index.html

"Can anybody point me to the classes that has to do with the Snap-in technologies? I've found some Midi related classes (but no MidiOutput?) but I couldn't see the plug-in related classes..."

Never mind. I've found it. AudioFilterBase, right?

And by the looks of it has the same crappy design as the original VST SDK.

[sigh]

[obiwanjacobi]

I've published my VST SDK design ideas in a
blog post.

[Hovmod]

Rewire is a free protocol, but you have to apply for the SDK and your company has to be be licensed by the Propellerheads. I doubt if they will give you a license if your expressed intention is to write an API that gives anyone access to the Rewire protocol.

[bradr]

I've published my VST SDK design ideas in a
blog post.

Hi Marc,

Nice job, though I'm actually in two minds re the message protocol vs interface approaches. For a long time I was a fan of interfaces, but the simplicity of message based protocols has grown on me recently. Both have pros and cons and both have their place.

For a .NET interop for VST I would probably use interfaces too but here's some things to consider:

* it's harder to write a logger/spy/stub+proxy/whatever to sit between a plugin and host with interfaces than it is with message model - particularly as you can just forward unrecognised messages. Its more difficult to forward an unrecognised interface.

* I wouldn't suggest using the existance of an interface as an indication of capability - sometimes the capability of plugin might need to be decided at runtime and depending on language/technology it may not be easy to change from implementing/not implementing an interface at runtime. I'd suggest qualifying the capability with a function on the related interface.

* As an API grows I've tended to notice that interface based APIs seem to get exponentially harder to understand/grasp (take a look at the ActiveScript debugger interfaces for example, or ActiveX controls) - often raising questions like who implements what, what are the dependencies between interfaces etc... similar problems exist with messages but for some reason they never seem to be quite so daunting - the learning curve seems to stay more linear. (if that makes sense)

Otherwise, nice blog and obviously well thought out.

Brad

[bradr]

Forget to mention - if you're doing .NET interop, have you looked into the C++/CLI/IJW ("It Just Works") stuff in VC 2005? If not I'd thoroughly recommend it. In my day job we spent a bunch of time testing this stuff out and it really did seem to be the best (ie: fastest/simplest) way to interop large API's between managed and unmanaged code.

Brad

[obiwanjacobi]

Thanks for your suggestions and comments, Brad. You bring some good points to the table.

* Yes, I intent to use C++/CLI to make the jump to .NET. It is clearly the best approach available at this time (although I have to brush up on my C++ again!).

* The Interop framework itself will be part C++ and part C#. Because I'm planning on interfacing with the core VST interface and not the SDK classes, I think the amount of C++ code will be minimal.

* I think its pretty easy to allow a chain-of-responsibility extension point at the low-level message exchange points (both for the host and the plugin).

* Dynamic feature support with interfaces will be hard indeed (unless you go for a QueryInterface type of solution). Any tips/hints on what features might typically be implemented dynamically?

* Evolving interface vs messages? My goal is to provide a structured framework for implementing (managed) VST plugins. If I would keep it down to message level I would only have a unmanaged-managed transition and I would have no chance to remedy the imperfections of the VST interface itself. Of course you have the always-returning interface versioning problem, but I think I will just postfix all interface names with the VST version (for instance for the VST 2.4 version: IVstPlugin24) it was designed for.

Good feedback, thanks!
More please, more!

[bradr]

* Yes, I intent to use C++/CLI to make the jump to .NET. It is clearly the best approach available at this time (although I have to brush up on my C++ again!).

* The Interop framework itself will be part C++ and part C#. Because I'm planning on interfacing with the core VST interface and not the SDK classes, I think the amount of C++ code will be minimal.

Yep shouldn't be too bad, though you're going to need special handling for each message type to "marshal" strings/pointers correctly.

* Dynamic feature support with interfaces will be hard indeed (unless you go for a QueryInterface type of solution). Any tips/hints on what features might typically be implemented dynamically?

Two main cases 1) loggers/diagnostic tools that just "re-host" another plugin 2) plugin construction kits eg: when implementing tools such as SynthEdit and SynthMaker you don't really know what the plugin designer is building, yet you wouldn't actually generate different code for different plugins - you'd use a fixed interface implementation that dynamically changes capabilities depending on the designed plugin. If you just allow the final declaration of capability to lie with a method on the interface its not a problem.

* Evolving interface vs messages? My goal is to provide a structured framework for implementing (managed) VST plugins. If I would keep it down to message level I would only have a unmanaged-managed transition and I would have no chance to remedy the imperfections of the VST interface itself. Of course you have the always-returning interface versioning problem, but I think I will just postfix all interface names with the VST version (for instance for the VST 2.4 version: IVstPlugin24) it was designed for.

Wouldn't .NETs assembly versioning and side by side assemblies resolve all this for you. So you'd have an interop dll for VST 2.4 and when a new VST spec comes out, just build a new interop dll with the interfaces updated?

Good feedback, thanks!
More please, more!

No problem. Sounds like a fun project.