Subject: Re: [linux-audio-dev] comments on benno's ideas
From: David Olofson (david_AT_gardena.net)
Date: Fri Mar 31 2000 - 03:27:32 EEST
On Tue, 28 Mar 2000, Paul Barton-Davis wrote:
> >My personal opinion is that Richard puts too much emphasis on keeping
> >the API as simple as possible ,while not looking at flexibility.
> >We have to learn from the past: a good design will last for years (see Linux)
> >and will avoid future incompatibilities and problems.
>
> I don't believe this. I don't think that anyone really knows how any
> of this stuff is supposed to work right now. We (including Digidesign,
> Steinberg et al) are all experimenting with it. There is some sign
> that the plugin approach is a good one, but as to the details of the
> API - I think we're at least 2 years from having a good handle on how
> a long-lived solution should look.
I have to agree with some of this. We don't really know enough about
what we're trying to do to tell what makes sense and what's just API
bloat. Still, I get the feeling that there are a few sensible things
that don't seem to fit naturally into an API of the LADSPA kind. Too
many compromizes for every single feature that anyone tries to strap
on.
To me this indicates that the basic design has a problem in the
first place. Many APIs are based on similar fundamentals to those of
LADSPA, and they all seem to run into similar problems. My
instinctive thought is that some radically different designs need to
be tried out.
I started to believe that LADSPA could do the normal stuff nicely in
something like it's current form, and then be extended with multiple
data types, the event system and that kind of stuff as needed. Once
again, I remember why I left this kind of design for something very
different. I've seen most of these problems before, and here they are
again! I'm now (at least) 90% convinced that anything like VST 1.0 or
LADSPA is not the way to go in the long run.
As for strapping the event system onto LADSPA; it does seem logical
in some ways, and the structures are similar, but the complicated
part - how to use the structures - is fundamentally different in some
important areas. I almost forgot that *that* was almost the whole
point with the real MuCoS design I was working on.
Basically, keeping anything but a false low level "compatibility"
between the two will break MuCoS, and possibly the mutated LADSPA as
well. For example, there is a conflict between LADSPA control ports
and MuCoS events. There is a conflict between LADSPA signal (audio)
ports and MuCoS "new buffer" events. There is a conflict between
MuCoS' terminator event and the LADSPA number of samples argument to
run(). MuCoS has channels while LADSPA has ports, and the semantics
are different.
MuCoS gets broken bordering to useless if it's not treated as a
cooperative RTOS IPC API ( <- check that one out! :-), while LADSPA
hosts (and/or their developers) will go nuts if they try to work that
way.
In short, too many of the similarities turn out to be illusions. I'm
going back to my radical, 99% event based idea, to see if it can do
more useful stuff without the creeping featurism symptoms.
> Thats why I support the notion that LADSPA (v1.0 at least) should be
> really really simple. We can experiment with it, and see what we
> think. Given that I don't think anyone on who has posted on LAD has
> ever written a VST plugin, we're in a pretty weak position to comment
> on whether or not multiple or single datatypes makes sense.
True. I can't say that I know if it'll really be needed for normal
audio processing.
However, I am very sure that it's *required* if the API is supposed to
be suitable for anything more than what DirectX or VST is used for
now. Then again, that's no excuse if the API becomes three times as
complex just because it's not dedicated to basic audio processing.
(Not that multiple data types is that complex, but that's just *one*
issue that causes general confusion and risk of list server overload
around here... What's next?)
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Fri Mar 31 2000 - 07:28:16 EEST