Subject: Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins
From: David Olofson (david_AT_gardena.net)
Date: Thu Nov 30 2000 - 05:43:24 EET
On Monday 27 November 2000 18:16, Kai Vehmanen wrote:
> 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. :)
Yep, full cycle completed! :-)
> 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)
LADSPA has clearly passed this test... :-)
> - it the API is too complex, nobody will write plugins
...so don't break it by strapping too many extensions onto it!
> - if we don't come up with something concrete, some other -
> possibly a very badly designed API - will become the
> standard (=what people use)"
Yes. Might have been a half-finished MuCoS thing that couldn't do
half of what MAIA will, at double the complexity... Although it looks
pretty simple now, you wouldn't believe how many times I've had to
rethink it all to get it right! (If I *did* get it right, that is...)
> 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
Audio ports have Data Type Descriptors, that hosts have to match when
making connections. Converter plugins, libraries or inline code can
be used to convert data if needed.
> - not enough support for multichannel streams (interleaving,
> etc)
See above.
> - no support for allocating memory using the plugin API /
> bounded instantation time problem
Still not sure what to actually provide here. The API is the easy
part here.
The average MAIA host will have two "dynamic" memory subsystems to
support the API. One is the event pool (linked list LIFO stack of
fixed size blocks - 32 bytes for 32 bit archs), and the other is
whatever the host uses to manage streaming buffers. (The latter is
similar to what LADSPA hosts have to do for audio ports.)
I'm thinking about allowing plugins to use these for some kinds of
dynamic allocation. The event pool can actually be used that way
right now - call it a bonus feature...
Organizing streaming buffers in a similar way (LIFO stack of equally
sized buffers) has several advantages over static buffer allocation,
so it might be a good idea to design hosts that way anyway. (Freeing
buffers after use and then dynamically allocating buffers increases
the chance of recycling buffers that are hot in the cache.) That
would make it easy to provide an API for (de)allocation of such
buffers for "private" use by plugins.
The most flexible, but also hopelessly complex solution is to provide
a more or less malloc()/free() compliant API. This is of course very
easy to use, and *very* easy to "implement" on soft RT and off-line
hosts, but you get to pay for it if you're into hard RT... Check out
the kernel memory manager (if it still looks the same?) - that's a
*simple* solution, with some restrictions. (RTAI has something
similar that's designed for RT apps, but I haven't had time to study
the code yet.)
> - no support for events / sample-accurate control
Well, that's what the entire MAIA protocol is *based* on. :-)
> - data ranges - currently both control data and audio data
> are not normalized to any specific range"
This can't really be done in any useful way with audio plugins. The
most sensible thing along these lines I can think of is dynamic
integer formats. That is, basically FP formats where an entire buffer
shares a single "exponent" field. That's a nightmare to work with,
and doesn't belong inside DSP nets.
*What* do people actually want with this? I've still not seen any
sensible mathematical or other explanation why one would want a
normalized range. To me, it looks like "math utopia", but I might
still be missing the point...
MAIA will simply define a "recommended 0 dB level" for signal data
types, so that audio plugin writers will have some idea about what to
expect.
> 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).
This is part a plugin implementation issue, part an API issue. The
host may have to provide RT memory management, plugins need to be
deterministic WRT instantiation time/CPU usage, and plugins have to
tell the host about it for any of this to make any sense without
forcing *all* plugins to be RT instantiation capable.
> 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.
Right; I don't see how the above can be incorporated into LADSPA
without giving it the VST 2.0 syndrome (multiple interfaces with
overlapping functionality), and I don't see how anything with a
sample accurate event system can be as simple and efficient as LADSPA.
Meanwhile, almost any plugin API can handle plugins that host plugins
using almost any other plugin API, so why chose? I think LADSPA and
MAIA will cover a huge range of applications with some overlap, and
at the same time offer very efficient solutions for most problems.
One size doesn't fit all, but two sizes might come close...
//David
.- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter |
`-----> http://www.linuxdj.com/mucos -' `---> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Thu Nov 30 2000 - 08:58:28 EET