[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: [linux-audio-dev] will LADSPA be part of MuCoS ?
From: Benno Senoner (sbenno_AT_gardena.net)
Date: ti maalis 07 2000 - 15:05:20 EST


On Tue, 07 Mar 2000, Richard W.E. Furse wrote:
> Hi there - nice API.
>
> I've been trying to persuade the list to endorse a nice simple plugin API
> standard that is compatible with *all* the current hosts out there at the
> moment (e.g. MN, aRts, Quasimodo) with minimum hassle. This is an extremely
> simple API that doesn't attempt anything in the least bit clever. The idea
> is to go for the most complex API that will work with everything out there
> with the minimum of wrapping. No threads, no sockets (the host is free to
> use these if it wants), no events, even only one data type (float).
>
> An alternative would be to use a heavier-weight API, but there are so many
> variations on this already (Quasimodo has one, MN has one, MuCoS uses
> another, Glame has one etc) and the assumptions of each make it difficult
> for other systems to wrap it. Rather than have everyone argue about how
> their system does things best, the idea is to find the common ground so no
> one's code has to be modified significantly.
>

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 ?

(there could be a flag in the plugin that indicates wheter this is a
LADSPA-only plugin or a full MuCoS 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.

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.

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.
(remember : Process() and ProcessReplace() are important, sorry for stressing
that again).

Benno.


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