Subject: Re: [linux-audio-dev] do YOU support LASDPA? (was Re: Linux Audio plugin API's: where are we ?)
From: Richard Guenther (richard.guenther_AT_student.uni-tuebingen.de)
Date: Fri Apr 07 2000 - 12:16:51 EEST
On Thu, 6 Apr 2000, Kai Vehmanen wrote:
> Please read on... important question coming up! :)
>
> On Thu, 6 Apr 2000, Richard Guenther wrote:
>
> >> (b) write multiple specialized APIs, or (c) a compromise API (=LADSPA).
> > too - so the point of having LADSPA is to write plugins that run
> > (inferior) on all hosts? This doesnt sound that interesting, though.
>
> Well, not exactly. IMHO the only real point is whether people will
> write plugins. If there are hundreds of good plugins available, we
> are all going to be interested. All other issues are secondary, because...
Well, I personally will not write LADSPA plugins for GLAME as that would
be pointless as GLAME has its own native plugin interface (superior, of
course :)))). But I dont mind if other people develop LADSPA plugins that
GLAME will be able to use (it will).
> - if the API isn't technically good and flexible enough,
> developers won't accept it (=start ot use it)
> - it the API is too complex, nobody will write plugins
> - if we don't come up with something concrete, some other -
> possibly a very badly designed API - will become the
> standard (=what people use)
>
> I know there a few hundred people reading this. Now I'd really
> like to hear from as many of you as possible: are you interested
> in adding LADSPA hosting to your app and/or write LADSPA plugins?
> If not, please tell us why. If the API is not good enough, what's
> the biggest problem? ...
>
> - static type for control and audio data, currently a 32bit float
perfectly valid assumption
> - not enough support for multichannel streams (interleaving, etc)
dont know - I personally thing interleaving is evil, I also think some
plugins will profit if a non predefined number of inputs/outputs can
be assigned (as far as I can see all those plugins will reside in the
host of the really too host-centric LADSPA design).
> - no support for allocating memory using the plugin API /
> bounded instantation time problem
non-realtime is no problem. Missing flexibility in the handling of the
buffer allocation/passing is.
> - no support for events / sample-accurate control
You can simulate this by adding another sample input?
> - data ranges - currently both control data and audio data
> are not normalized to any specific range
Duh. This is bad - you are restricted to 32bit floats - why not limit
the range to [-1, 1] then, too?? Is the limit at least somehow "static"
declared?
But now my main point. LADSPA is designed to be a _binary_ interface!
LADSPA could be more easily (efficientely) adoptable by different hosts
if it were a source level compatible plugin interface, i.e. a host has
to provide a certain set of interface functions. Of course some of them
will be #defined to do nothing on some hosts, some will be rather complex
in their implementation, also the host centric approach does not work for
this - buffer handling needs to be done explicit by the plugin (at least
in the source), but can of course be clever #defined to nothing. After
all, we are an opensource community! We should use the power that such
an approach provides.
I know I should have raised this point more early but I just didnt see
what I dislike about LADSPA and how to solve it. LADSPA v1.0 is really
a "Schnellschuss" (whats this in enlish??) I think... at least to be
adopted as main plugin interface for more than a handful of projects.
> If you have no objections, then please, add LADSPA support to your apps...
> It's the only way we can get this started. If it turns out, that nobody is
> interested, then we just have to improve the design or spend our time
> doing something else.
GLAME will have support for running LADSPA plugins (I'm sure its possible,
whether it is efficient is another question). If LADSPA becomes widely
adopted this support may be supported by doing some tweaks to the GLAME
plugin interface to more efficient support this embedding.
Richard.
> As for myself, all my apps already support LADSPA (through libecasound
> library). I've even coded a simple generic GUI (see ecawave's
> CVS-version). For my uses, the current API is enough.
>
> And as a last note, no, I don't think we should stop development.
> I'm all for developing MuCos/LASDSPA-v2 with support for events,
> multiple data types, VST, etc ... but this shouldn't prevent us from
> writing LASDAPA-v1 code. For many cases, the current API is enough.
>
> --
> Kai Vehmanen <k_AT_eca.cx> ---------------- CS, University of Turku .
> . audio software for linux ... http://www.eca.cx .
> . armchair-tunes mp3/wav/ra .. http://www.wakkanet.fi/sculpcave .
>
-- Richard Guenther <richard.guenther_AT_student.uni-tuebingen.de> WWW: http://www.anatom.uni-tuebingen.de/~richi/ The GLAME Project: http://www.glame.de/
This archive was generated by hypermail 2b28 : Fri Apr 07 2000 - 13:21:36 EEST