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

[jwatte]

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.

I can assure you that I've put a lot of thought into this topic, over more than ten years. I also started thinking about a replacement, for real, a year ago when VST 3 turned out to be such a poor replacement for 2. At the time, I asked the same questions here (sans code), and someone set up a discussion forum for what a replacement could be, but that never seemed to go anywhere.

Hence, over Christmas break, I spent two solid weeks not only writing a specification (specifications are easy , but writing a real, honest-to-goodness implementation, that includes a synth, a reverb, a gain, a file player, a file recorder, MIDI in and out and audio in and out. As well as a GUI to drive it all. My mantra is: Working Code. If you don't have working code, then you have nothing.

The reason I'm looking into starting from scratch is not that I want something new, but that I want something that is:

1) Platform independent (DXi doesn't do this)
2) Documented as a specification on the plug-in side (VST is shaky here)
3) Documented as a specification on the host side (almost none of the alternatives do this).
4) Supports all the features we know we'll need, like side-chaining, multi-channel, latency compensation, rich metadata about connections, sample-accurate automation, etc. (Except for VST and perhaps DXi, the others fall down here)
5) Not controlled by any single one vendor. (A real problem)

You can find APIs that do 1, 2 or even 3 of these. However, I haven't really found any API that I would say aced four of them, much less all five. And I have looked! I'm not looking for pointers to web forums here; I'm looking for actual, honest feedback on the actual, honest proposal and code that I've put together and made work as a whole.

What I have gotten out of this thread so far is:
1) It must provide wrappers for some other APIs, too, or nobody will bother.
2) It must be simple to write a plug-in. Don't make people write boilerplate code.
3) Abstract C++ interfaces are probably just fine for a specification; no need to go back to 1980 with a C interface.
4) Host developers haven't reallly chimed in, so I have no idea whether the idea of providing strong support and specifications for host behavior is actually a major benefit or not (but I still believe it is).

[djex]

4) Supports all the features we know we'll need, like side-chaining, multi-channel, latency compensation, rich metadata about connections, sample-accurate automation, etc. (Except for VST and perhaps DXi, the others fall down here)

I think you will even want to support all the features you don't know you'll need! If you plan on your format being used in favor of a native AU/VST/... plugin you'll have to support all features of the underlying AU or VST or whatever format--even features that don't make much sense from your point of view and that may be unique to a single format. If you restrict your format to "useful" features some (for example) AU-specific things won't be possible by using a wrapper, in effect forcing "serious" developers to abandon your format and make a native AU plugin after all. Freeware developers probably won't care that much but if you have to run a business you can't afford to leave out standard functionality that your customers expect.

-- dj!

[nollock]

If you restrict your format to "useful" features some (for example) AU-specific things won't be possible by using a wrapper, in effect forcing "serious" developers to abandon your format and make a native AU plugin after all. Freeware developers probably won't care that much but if you have to run a business you can't afford to leave out standard functionality that your customers expect.

Well imo the way to do that would be to allow people access to the underlying API. So they can code to the new API, but also access the underlying API that is being wrapped, (if they need to). Eg. Most Win32 toolkits allow you to grab window handles or HDCs if you want them.

That might get kindof tricky if you're wrapping 3 or 4 different plugin formats though.

[4damind]

I would set the focus to "free". The problem with VST: it's owned by Steinberg and the license gives many restrictions to have VST support eg. on Linux.

We need an open and free plug-in format / SDK and not only another format owned by a company.

[jwatte]

If you restrict your format to "useful" features some (for example) AU-specific things won't be possible by using a wrapper, in effect forcing "serious" developers to abandon your format and make a native AU plugin after all.

Point taken. I stopped developing for the Mac about 13 years ago, though, so I'm not up an much anything after System 8. Is there someone in this forum who knows Audio Units, and is willing to read up on the spec and figure out what's missing? Otherwise, I'd probably keep trucking on, and once I get around to writing a Mac version, I'll get to "version 1.1: now with AU integration."

And when it comes to free: I'm doing this totally for free, out of a love of the industry. Currently, the code and specification text is public domain. Don't get much free-er than that