Subject: Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Mon Nov 27 2000 - 19:16:27 EET
On Mon, 27 Nov 2000, Steve Harris wrote:
>> "LADSPA is VST1.0 done right, MAIA will be VST2.0 done right".
> OK, fair enough, but there is a certain "lets redo the API and get it even
> righter this time" attitude (with appologies for the english).
> Sophisticated API's are great, but actual working code people can use
> /now/ is great too.
> LADSPA has the advantage, on top of all the obvious ones, of existing.
Heh, major deja vu here. :) Quoting my own message, dated Thu, 6 Apr 2000:
"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...
- if the API isn't technically good and flexible enough,
developers won't accept it (=start to 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)"
Then I continue (throwing a question to other LAD members):
"... 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
- not enough support for multichannel streams (interleaving, etc)
- no support for allocating memory using the plugin API /
bounded instantation time problem
- no support for events / sample-accurate control
- data ranges - currently both control data and audio data
are not normalized to any specific range"
As far as I remember, only one serious problem came up. James McCartney
reported that his SuperCollider software absolutely requires 3
(plugin instantation must be rt-safe).
During the last few weeks, at least items 1, 4 and 5 have once again been
discussed. I don't know about you, but my feelings are still the same. All
of the above features are important, I guess we all admit that, but at the
same time these features are someting that many of us can live without. On
the other hand, by leaving these features out, we took a huge leap towards
simplicity. Adding features is easy - knowing when to stop, _that's_ the
difficult part.
Now correct if I'm wrong, but my understanding is that the above features
are still outside LADSPA scope. So the current discussion concerns only
MAIA. And yup, there's still a place (and need) for MAIA. I see it a
natural layer above LADSPA. I guess the XML-GUI now under planning is a
good example of this. It is not extending LADSPA directly, but is built on
top of it.
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ .
This archive was generated by hypermail 2b28 : Mon Nov 27 2000 - 19:36:53 EET