What the World Needs: a New Plug-in Format!

[jwatte]

Honestly I won't try to do a plugin format
if I've never done some serious plugin, both instrument and effect with stuff like surround capabilities, internal sequencer and other advanced stuff.
No offense, but it's trying to do a compiler when you don't know all the language requirements.

Luckily, I have a rich background in real-time multimedia. I have (in my professional life) written sound and video drivers, I have written plug-ins, I have written hosts, I have even worked on OS kernels, compilers and debuggers, all since the early '90s. I believe I'm actually fairly qualified to know what the requirements are for both hosts and plug-ins.

I also think that the actual specification I posted encompasses a fair bit of my knowledge so far. If you would do me the favor of actually reading the headers with comments, and then commenting on what you think is wrong, I would appreciate it. The questions I now have are more along the lines of "did I miss something" or "did I make the wrong choice" or "is there something that would make this API harder to use than necessary." I think I know what I'm doing at the base level

One thing I focus on, and which the others don't, is clearly specifying what the host requirements and protocol is, including threading. This means that building a stable system becomes easier. I also focus on providing an example hosting library, which makes adding support to a host as easy as possible, which I believe the others don't do.

When it comes to other independent plug-in formats, such as LADSPA/LV2, if anything, those are designed without regard for the real problems of such plug-ins, as witnessed by the lack of support for things like multi-bus support.

Perhaps the work will end up being something like a wrapper for VST 3 that implements hosting on one side, and a simpler plug-in API on the other, who knows. But, currently, that looks less desirable to me.

[jwatte]

I think the biggest problems with VST are lack of documentation and stability as all plugins run in the same address space and can crasht the host and one another. My thoughts are about a plugin format in which each plugin runs in its own separate process.

It turns out that I spent three years of my life about ten years ago trying to make exactly that idea work. In the end, it actually worked, but it turned out that it was useless, because:
1) The overhead was higher than an in-core host, even on an OS designed explicitly for this use.
2) When one part of the signal chain goes down, chances are that it's a part you care about anyway (else it wouldn't be there). A crash is a crash.

Think of it as live PA. What would you want to have go down? Your compressor, your mixing board, or your amp? The answer is that you're pretty much screwed no matter which one goes down...

Thus, I learned that the lower overhead and simpler programming and system model of in-process plug-ins is generally not only good enough, but usually actually better.

[Resplendence]

1) I believe this can give some headaches but you can get very good IPC performance with memory mapped files.

2) Currently because all plugins run in the same address space, it is very easy to crash another plugin running in the same host or the host itself. The host is usually put to blame but the problem rarely resolved or the wrong plugin removed. When each plugin runs in its own space at least you can tell for sure what process is crashing so you can look for a replacement plugin.

//Daniel

[aciddose]

ok, so you could put each module in it's own box with it's own power supply and handle them individually, but you won't because it's easier. so which would you rather have light on fire, your preamp, your compressor or your driver? any one of them can light up and burn all the rest of the modules, not to mention mess up the project you have been working on, write corrupt data to the drivers and cause the whole system to require a reset. yeah, that sounds much better, let's do that.

i don't have a problem with doing that actually, just don't try to make excuses like "it's faster not to". tell the truth: "it's too much work to do that."

[jwatte]

1) I believe this can give some headaches but you can get very good IPC performance with memory mapped files.

We used shared memory for data buffers. The problem is how each process can know that it's ready to process, which needs some kind of IPC synchronization (such as semaphores or events). That means that, for each buffer, for each plug-in, you have to enter the kernel, and the kernel has to context switch to not just another thread, but another process (which has another MMU context, etc).

Trust me: been there, done that, NOT WORTH IT!

Save often.

[hill_matthew]

As good as the author's intentions no doubt are, I also don't think any major host vendors will adopt the new plugin format no matter how good or innovative or whatever it may be. It's hardly a coincidence that Steinberg hosts support only VST, ProTools recognizes nothing but RTAS and TDM, and for Logic it's AU or no go. In marketing terms this is probably called "establishing a customer base".
-- dj!

I really agree. So I think the direction we need to see is as demonstrated by Juce (http://www.rawmaterialsoftware.com/juce/) where you wrap the existing evils (that the big host companies will never want to go away) and provide a simple programming interface to hide it all.

The problem with Juce if you want to release closed source free or cheap plugins is the GPL as the licensing costs for a non-GPL copy are just too high for that. So I'd love to see effort going into a Juce-like API just for plugins which provides cross-platform compatability using the BSD license. The GUI could even be handled by VST-GUI which many people are familiar with (it's also using BSD on sourceforge) and already cross-platform.

[Jeff McClintock]

"did I miss something" or "did I make the wrong choice"

GMPI Requirements - a very comprehensive plugin standard design. Well worth reading for inspiration.

http://retropaganda.info/archives/gmpi/ ... draft.html

My implementation of GMPI (called SEM), tweaked for modular synthesis but still mostly generic. BSD License. Please take any code or ideas you find useful.

http://www.synthedit.com/sdk3_docs/index.htm

Good luck,
Jeff McClintock

[mateo]

The problem with Juce if you want to release closed source free or cheap plugins is the GPL as the licensing costs for a non-GPL copy are just too high for that. So I'd love to see effort going into a Juce-like API just for plugins which provides cross-platform compatability using the BSD license. The GUI could even be handled by VST-GUI which many people are familiar with (it's also using BSD on sourceforge) and already cross-platform.

Wasn't that exactly what infinity was? http://www.expdigital.co.uk/legacy2/developers.htm

[hill_matthew]

Wasn't that exactly what infinity was? http://www.expdigital.co.uk/legacy2/developers.htm

Well, almost, it's perhaps picky to moan about its license, putting a small logo and statement in the about box isn't a huge issue really, but I feel like there could be some benefit to a BSD-based API that the community and even industry could get behind. Does anybody have any experience using Infinity API to comment on its robustness and general quality? Their forum was down when I tried which was a bit discouraging...

--- Edit ---

And looking more closely, it only seems to support VST, is that right? If so, my previous post stands as AU and RTAS etc are really needed for a multi-platform plugin system with a relaxed license.

[mateo]

Well, almost, it's perhaps picky to moan about its license, putting a small logo and statement in the about box isn't a huge issue really, but I feel like there could be some benefit to a BSD-based API that the community and even industry could get behind. Does anybody have any experience using Infinity API to comment on its robustness and general quality? Their forum was down when I tried which was a bit discouraging..

Yeah, I do think that the license, as simple as the requirement is, is an obstacle to its widespread adoption. Any lib should ideally be a community effort, not a gift from a single developer.

In any case, it seems exp digital have thrown in the towel, so to speak, which is I guess why their forum is down.

And looking more closely, it only seems to support VST, is that right? If so, my previous post stands as AU and RTAS etc are really needed for a multi-platform plugin system with a relaxed license.

Right, AU support was planned, but I guess they never got around to finishing it.

--

edited for spelling

[jobromedia]

VST2 is more than enough for my needs. So the answer is no.

[jwatte]

VST2 is more than enough for my needs. So the answer is no.

Are you a host or plug-in developer?

[duncanparsons]

Wasn't that exactly what infinity was? http://www.expdigital.co.uk/legacy2/developers.htm

Well, almost, it's perhaps picky to moan about its license, putting a small logo and statement in the about box isn't a huge issue really, but I feel like there could be some benefit to a BSD-based API that the community and even industry could get behind. Does anybody have any experience using Infinity API to comment on its robustness and general quality? Their forum was down when I tried which was a bit discouraging...

--- Edit ---

And looking more closely, it only seems to support VST, is that right? If so, my previous post stands as AU and RTAS etc are really needed for a multi-platform plugin system with a relaxed license.

If you ask nicely, Paul might let you have the version with AU support, but it was never actually released. There are a few bugs, but essentially it's a good wrapper

DSP

[bvesco]

Does anybody have any experience using Infinity API to comment on its robustness and general quality?

I tried porting a few plugs to it. It was quite a pleasure to work with and was of generally high quality. I did find a few buried bugs though which made me lose confidence in the overall reliability of core functions. Two main things which I reported at the forums:

- operator+ and operator+= for custom types BOTH do the exact same thing (which is to work like +=). When I brought this up at the forums the response was, "yeah, you're right, but I hardly ever use overloading anyway." Well, if you don't use overloading then why include it. If you include it for the benefit of your "customers" then support it, and make it right. That's not an appropriate support response to a core library bug.

- There is are some "fast" math functions of which one is fastFloor which isn't a floor function at all, but actually a rounding function. Again, brought this up on the forum and the response was ultimately, "It works fine on my mac." Which is not an appropriate support response again.

So in the end I feel like Infinity is a great idea for an API with a poor execution. I'm happy to contribute fixes back to an open source community API but what I don't want to do is use a library that I don't have confidence in. I certainly do not have confidence in the Infinity API. I do have confidence in VST/VSTGUI and WDL/IPlug.

Any new plugin API on the scene needs to instill developer confidence.

[plastique]

Well, I first planned to contribute something to the ideas here but after some more thoughts and reading other replies I decided to vote for "No", and turn away from this idea, with bascially two reasons.

First, it seems that the majority (probably mostly also the plugin developers) will just be fine with VST2.x for quite some time (that's me included), and that's what the starting point for an imaginative new plugin standard would be for myself, and second, VST3 is still in baby shoes, and maybe it does grow up enough to get all the features from VST2.x (*).

Starting a new format from scratch just to have something new, without any effort to think about the what is already there, makes no sense to me. So a friendly, but well thought out "No". I think it's good that those issues are discussed here in general, and it seems that this thread also spawned some interesting discussions about how things could be implemented, which I think is quite cool


(*) And no, I don't care about this speculative VST3-to-VST2 wrapper, which seems kinda pointless to me. Why sacrifice the performance of VST2.x plugins if you can have the real deal ?