Re: [linux-audio-dev] will LADSPA be part of MuCoS ?

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

Subject: Re: [linux-audio-dev] will LADSPA be part of MuCoS ?
From: David Olofson (david_AT_gardena.net)
Date: ti maalis 07 2000 - 21:34:53 EST


On Tue, 07 Mar 2000, Benno Senoner wrote:
> Richard, you are talking as if LADSPA were yet another API within the
> plugin-APIs pool.
> Maybe it's only my impression,
>
> but my wishes are that we should agree on one single standard.
>
> Therefore the ideal would be if LADSPA would be
> the plugin-API (DSP processing without events) , of MuCoS.
>
> That means the complete MuCoS host will be able to run
> LADSPA-type and event-based plugins,
> while the simple LADSPA host (for games,etc) will only be able
> to run LADSPA plugins.
>
> Is this ok ?
>
> opinions ?

I was just about to post a document where I describe a possible way
to do this nicely. :-)

> (there could be a flag in the plugin that indicates wheter this is a
> LADSPA-only plugin or a full MuCoS plugin)

In my proposal, this "flag" is what you get if you find no MuCoS
event ports on the plugin.

> As for the datatypes: meanwhile we can begin to do our work based
> on floats, but we should keep a door open to easily allow double precision
> FP within plugins and host.

Yes... I still think that data pointers should be void *, and the
expected (required!) data type specified somewhere in the API, but
that's not really a big change. Those who don't feel like hacking
prototype engines with built-in non-float data support (we have no
conversion plugin array yet) can just make their engines refuse to
run plugins with anything but float ports.

> The recommendation for the plugin developer will be :
> "use only float for performance , unless you havevery strong reasons,
> to avoid it (because you need double FP to avoid error propagation in
> some special bad conditioned mathematical problems).
>
> I don't think that the data conversion plugins will bloat either host or plugin
> code, since there aren't that many data types.

Right, and you don't even need to have them in the code. Providing
them as normal plugins is probably the easiest way to get started
with a new engine.

> Anyway we should provide VST 1.0-like (no events) functionality in LADSPA in
> order to give the developer a tool to develop useful plugins.

Yes, and I think it's possible to do that without too much
overlapping functionality in the actual process time part of the API.

There is a problem with the initialization and other out-of-band
suff, though. This might end up looking like VST 2.0, which means
that there is *a lot* of engine code to hack in order to make is
possible to control plugins remotely.

The MuCoS idea is to do this through the event interface, allowing
RPC style interactions between engines. Also, the event system makes
it possible to extend the API without breaking binary compatibility.
That reserved area of LADSPA is not needed in a MuCoS plugin, as
there is next to infinite room for expansion in the event API.

> (remember : Process() and ProcessReplace() are important, sorry for stressing
> that again).

Yes.

I think output level support is useful as well (as it eliminates
extra plugins and copying for things like send levels and faders),
but this should probably be verified through some serious looking at
common mixer/synth/... structures. (I could be missing something, but
as far as I can see, that "something" would invalidate the usefullness
of process() and processReplace() as well...)

//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 : pe maalis 10 2000 - 07:23:28 EST