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 - 06:11:18 EET
On Monday 27 November 2000 18:13, Steve Harris wrote:
> On Mon, Nov 27, 2000 at 07:16:27PM +0200, Kai Vehmanen wrote:
> > Heh, major deja vu here. :) Quoting my own message, dated Thu, 6
> > Apr 2000:
>
> Good, I'm gald I'm not the only one that feels this way.
Speaking of which; I recognize this "more text than code" syndrome as
well... *heh*
> > - 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"
>
> The only one that has bitten me so far is 5 (for audio, not
> control, I like unbounded control ranges).
Is that really "bounded range", or possibly "defined 0 dB level"...?
> 3 would have been nicer I guess,
I don't know about "nicer", except that it's nicer and easier to
implement RT mm hosts behind a custom API than by overriding malloc()
and free().
As to RT memory managers, the only nice thing about them is probably
that they (hopefully) give you RT memory management... This is not an
API matter though, although a nice API could simplify the
implementations somewhat. (By defining maximum block sizes, maximum
amount of memory to allocate during one cycle and that kind of stuff.)
> and 4 might be a problem when I try to do stuff in
> realtime.
Timestamped events are basically a performance hack that fortunately
can double as a buffering system, IPC protocol, and some other
things. Nice, but far from trivial to design.
In the form events come in VST 2.0, they are *nothing* but a
performance hack - and that's what they'd look like if glued onto
LADSPA.
The reason why this isn't the case with MAIA is that MAIA is designed
around the event system, rather than the other way around.
> But I think they were all worthwile sacrifices for the S.
Yes, as they are all definitely not simple to deal with.
> > 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.
>
> Definatly, there is a need for a non S GPL'd plugin API.
Despite my statements in some other thread, MAIA is still LGPL.
I'm probably just not mean enough to make it pure GPL, which is
kinda' weird after what I've been though the last few years...
> And The work that has been done on MAIA sounds great.
Well, if the software is half as good as the vapourware...! Working
on that, and it looks good so far. :-)
//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:16:40 EET