Subject: Re: [linux-audio-dev] more on plugins/LADSPA
From: James McCartney (asynth_AT_io.com)
Date: Thu Mar 16 2000 - 02:29:01 EST
on 3/16/00 12:53 AM, David Olofson at david_AT_gardena.net wrote:
> 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.
Well unfortunately one API can't serve all needs.
SuperCollider needs real time instantiation, sample accurate start time,
dual rates on any input (arate & krate), variable block sizes per ugen
group. Since these are not supported or guaranteed in this API, so I am
unable to use it as my ugen API.
For example in the repatching case you mention in another post, SC unit
generators do have to know about this, because the calculation rate on one
of the inputs may have changed and the ugen may want to install a different
function pointer.
--- james mccartney james_AT_audiosynth.com <http://www.audiosynth.com>
SuperCollider - a real time synthesis programming language for the PowerMac.
<ftp://www.audiosynth.com/pub/updates/SC2.2.7.sea.hqx>
This archive was generated by hypermail 2b28 : Thu Mar 16 2000 - 17:41:29 EST