Re: [linux-audio-dev] more on plugins/LADSPA

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] more on plugins/LADSPA
From: David Olofson (david_AT_gardena.net)
Date: Thu Mar 16 2000 - 01:53:35 EST


On Wed, 15 Mar 2000, Kai Vehmanen wrote:
> On Wed, 15 Mar 2000, Paul Barton-Davis wrote:
>
> >> 1) Something like BeOS MediaNodes. Very heavy weight, more like full
> >> apps that can be piped together.
> >> 2) Statically allocated large processes/effects with GUIs,
> >> automation. VST
> >> and TDM plugins fall here.
> >> 3) Lightweight unit generators. MSP, Csound, SC unit generators.
> > I think that this is *VERY, VERY* important. We need to make sure that
> > we define the level(s) that LADSPA is intended to cover. Then we need
>
> Yes, this is an important question. I'm leaning towards option '2'.
> It's the easiest one, and thus fits the "simple" in LADSPA
> (and the current model). A good specification in case '1' requires a lot
> more work, while '3' isn't enough for everybody (= requires a more complex
> host).
>
> But hey, everyone else, what do you think? If our goal is to make LADSPA
> as widely accepted as possible, then the initial design should be usable
> 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
> API :)). When applications range from SuperCollider/Quasimodo -> mp3
> players, we have to make compromises.

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.

For example, the difference betweed MuCoS client/server and MuCoS
plugins is only the way of execution - the event system is the same.
The difference between LADSPA and MuCoS plugins (or LADSPA/MuCoS) is
only that the latter has event ports, while the former does not. The
difference between LADSPA/MuCoS Plugins/"LADSPA/MuCoS" and LUGAPI
would be only the real time instantiation capabilities, as far as I
can see.

I'd say that the same API could cover all but the highest level
(client/server, as this rules out the LADSPA ports in their current
form) can use the same API. The difference between plugins of the
lower levels would be only implementation details, and the associated
flags to tell the host about the resulting capabilities.

Put another way; the distinctions between the levels don't seem
"hard" enough to warrant API separation, as plugins can migrate
between the levels through minor adjustments of their
implementations. Can someone point out any other hard distinctions
than the thread vs. callback one, that would require a different API?

In the big picture, I can't see how multiple, separate APIs can be
simpler than a common API that can be used in some slightly different
ways. It only makes code reuse harder, makes it a big job to support
all APIs in a host, and makes life messier both for the developers
and the end users.

//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 -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Mar 16 2000 - 09:28:57 EST