Subject: Re: [linux-audio-dev] Linux Audio plugin API's: where are we ?
From: Jim Coker (jcoker_AT_jguru.com)
Date: Sat Apr 01 2000 - 01:44:58 EEST
A quick thought:
Adopt VST2.0/FreeST as a low-level common denominator API.
Rename LADSPA to be "Extended FreeST" and make it a superset
of VST2.0 (or if not a proper superset, make it compatible
enought that LADSPA hosts can host VST2.0 plugins
transparently).
Host implementors could then pick one of two levels
of support, and plugin writers could use the base
VST API when that is sufficient, moving
to the more complex level of support only when
necessary.
Jim
Paul Barton-Davis wrote:
>
> Dear LAD Folk -
>
> A month or so ago, Richard stepped forward and said that it was time
> to write some actual code for a Linux audio plugin API. He very
> sensibly aimed at an API that was a common subset of all existing
> applications that did something like what the API was intended for. As
> far as I know, he was aware of MN, Quasimodo, aRts and ecasound,
> possibly others.
>
> Within a short space of time, we got a fair amount of consensus from
> those *actually working on such applications* about what should go
> into the API. It was short, simple and *intentionally* limited.
>
> Since then, other people who for the most part are working on Linux
> audio software, but not as far as I know actively writing applications
> that do or could use a plugin API, have suggested all manner of
> extensions to LADSPA. Benno has even gone as far as trying to sketch
> out the next version of LADSPA before the current one is even
> released.
>
> James McCartney, an interloper (:)) who wrote the incredible
> SuperCollider program for MacOS, offered us some useful and cogent
> thoughts on data types and real time constraints.
>
> We have also heard from the folks working on GLAME, who have their own
> plugin API that they offered up as their desired target. It has some
> fundamental differences with the general design of LADSPA, in
> particular over the question of who should allocate and control the
> buffers used by plugins. However, even the GLAME folks seem willing to
> entertain the idea of LADSPA as the "lowest common denominator", which
> is what I understood Richard's original goal to be.
>
> Kai and others have wisely and sagely pointed out that without
> agreement over a plugin API, we will continue to see very little reuse
> of DSP code, and most developers will just continue with their own
> "plugin" API's.
>
> Meanwhile, I've gone ahead and done a very quick "port" of Steinberg's
> VST to Linux (a trivial task) and written a naive prototype of a VST
> host.
>
> We've also had some pointers to EASI, which like ASIO, is a "plugin
> API" designed not for audio processing, but for I/O "drivers". Both
> API's have some useful features in them.
>
> So, where are we ? On the one hand, we have the POV that LADSPA should
> be an incredibly simple plugin API, implementing just enough that
> existing Linux "plugin-ish" apps can adopt it. On the other hand we
> have the POV that LADSPA should incorporate forward thinking design
> that will enable it to accomodate all kinds of things that current
> plugin API's (such as VST) do not currently support.
>
> This is, to put it mildly, a serious dilemma. It is for this reason
> that I have been slowly sliding toward a 3rd proposal, which I have
> already described in passing. I favor the adoption of an existing
> plugin API, in particular VST, and I do so for the following reasons:
>
> 1) it exists
> 2) it comes with source code (most of it, anyway)
> 3) it is free of charge, and has an open license
> 4) it works for hundreds of existing plugins
> 5) it reflects several years experience with a plugin API
> 6) it has some extra features that LADSPA does not have,
> plus a few missing ones
>
> In addition, I believe that:
>
> *) If necessary, we can reimplement it as FreeST, and use
> our own (L)GPL license. I hope that this will not be
> necessary.
> *) By using C++, the API is easily extended to add new
> functionality while still offering backward compatibility.
> *) Using an existing (and very successful) API will attract
> more developers to Linux audio than a new API
> *) I think we can work with Steinberg to extend VST in the
> right direction.
>
> None of this is meant to dismiss the effort that people on the list
> have put into LADSPA. I think that the discussions have been extremely
> useful in fleshing out that a plugin API *should* look like. But I
> also think that they have demonstrated some of the typical problems of
> "design by committee".
>
> I do not believe that we will be able to achieve true consensus over a
> new API. Without true consensus, the new API will help a little, but
> will not solve the problem of code reuse and integration of neat new
> modules into various conceptually related but distinct applications.
>
> That is why I think it better that instead of inventing a new one
> right now, we begin with an existing one (or a reimplementation of an
> existing one if licensing issues arise). It provides a baseline
> functionality that has been sufficient for all kinds of neat stuff in
> the Windows/MacOS world, and even if everyone goes their own way with
> extensions, it will continue to offer a basic plugin API that plugin
> writers who want maximum compatibility can use.
>
> Writing a VST plugin without a GUI is incredibly easy, and I have
> written code already that could be used by any application to load,
> interconnect and execute a chain of VST plugins. I plan to start work
> on a GTK+ port of the vstGUI API, which should be fairly easy to
> write, if a little tedious.
>
> Finally, I would note that I consider VST to be an even "lower common
> denominator" than LADSPA, since it does not include the notion of
> "control ports". [ Aside: This is actually a difficult problem that sample
> accurate hosts would need to solve by playing games with the
> setParameter function ]
>
> I humbly submit to the list that this is a better path to follow than
> an continuing design committee for a new, untested API. I am NOT
> suggesting that VST2.0 is the holy grail of plugin API's, merely that
> its a better place to *start* from than LADSPA *DESPITE* the fact that
> LADSPA already contains a couple of features I think VST should have.
>
> --respectfully,
> --p
This archive was generated by hypermail 2b28 : Sat Apr 01 2000 - 02:06:41 EEST