Subject: [linux-audio-dev] Linux Audio plugin API's: where are we ?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri Mar 31 2000 - 21:09:36 EEST
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 - 00:34:24 EEST