Subject: Re: [linux-audio-dev] more on plugins/LADSPA
From: David Olofson (david_AT_gardena.net)
Date: Fri Mar 17 2000 - 23:00:51 EST
On Fri, 17 Mar 2000, Kai Vehmanen wrote:
> On Thu, 16 Mar 2000, David Olofson wrote:
>
> >> in as many projects as possible. It might not be such a bad idea to develop
> >> multiple APIs in paraller (MuCoS, LADSPA, LUGAPI (Linux Unit Generator
> > Parallel development of a few, slightly different APIs is good, but I
> > just don't think they'll end up being different enough to end up as
> > individual APIs.
>
> Hmm, I just feel that trying to put everything under the same interface -
> although maybe possible - will slow down the development. We already
> have many different approaches:
>
> - the current LADSPA model
> - realtime bounded API (memory allocation issues, realtime
> requirements, etc. - mostly unsolved)
> - GUI interaction -> GUI-specific plugin-APIs (no agreement)
> - sample-accurate, event-based API (MuCoS, as you've said, still
> vaporware)
> - ...
>
> The first one is ready (well, at least very close) for real use, but
> the rest is still pretty much an open field. Parallel development
> would mean, that we would start using LADSPA, while still continuing
> to discuss the other issues and plugin models. Sometime in the future,
> we may combine all (or some) of these APIs to one all-around API.
>
> And just to make sure, I'm not trying to say that the current LADSPA
> model is ready - I'm just saying that we have to draw the line
> somewhere.
The line, IMHO, is where we say that the current API spec is stable.
Before that, just about anything might change. We should try not to
break everything every other week, though, so an API that makes
some sense is needed before hacking away. I think we're pretty close
to this with LADSPA. As I suggested, MuCoS event ports can be a
LADSPA port type, actually more or less turning LADSPA into what I
meant MuCoS to be (ie, I don't have to work on the boring non event
relater stuff ;-), and most other things we have discussed can be API
extensions rather than fundamental parts of the API.
If we can agree on a basic API foundation that works for all of us,
merging the different extension efforts into a consistent API later
won't break all that much.
//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 : Sat Mar 18 2000 - 07:08:13 EST