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.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST