Subject: RE: [linux-audio-dev] LADSPA with multichannel and multi-dataype support almost finished,need opinions !
From: David Olofson (david_AT_gardena.net)
Date: Sun Mar 26 2000 - 02:07:37 EET
On Sat, 25 Mar 2000, Benno Senoner wrote:
> LADSPA , or LADPA ( S removed because some will think that my few extensions
> make it much more complex),
> has to cover all our audio-plugin needs.
> And we are just a step away from a flexible and powerful solution,
> limiting the API now, will lead to problems later, that's for sure.
Or to put it my way; why have multiple incompatible APIs with very
similar basic frameworks?
Actually, I'm planning not to design a separate plugin framework at
all for MuCoS, as LADSPA fulfills that function rather nicely with
minor modifications. Hopefully, these modifications can be part of
the standard API without complicating things for non-event enabled
hosts and plugins, which would mean that adding event support to a
host or plugin is basically adding support for a new port type,
rather than switching to another API.
> I think you are fearing incompatibilities between plugins and hosts if the API
> gets too complex.
> A 64bit-float-only plugin will not work with a 32bit-float-only host,
> but there will be a GUIDELINE:
With my version, they *will*. Hosts may run plugins without knowing
anything more than the size of one data element. Converter plugins
can be used whenever the host needs to understand the data, or when
connecting incompatible plugin ports.
> the recommended datatype will be 32bit-float, if a plugin-developer choses
> to support ONLY 64bit-float, then he has to take into account, that his
> plugin will not work with the majority of the "simple" host.
Ok, it *is* possible to write hosts that ignore the data types and
hardcode the element size into the engine, and then just refuse to
load plugins using other formats...
> Basically the host looks which datatypes are supported, and then
> instantiates the plugin with the desired type.
With my system, this is done by picking the most suitable version of
the plugin.
> > Multichannel support is already implicit in LADSPA through the multiple
> > port model. The only benefit of extending this would be to allow variable
> > channel counts, however this again falls beyond the scope of LADSPA.
>
> Yes I know that the multichannel support is implicitly already here,
> but I extended the concept a bit:
> variable channel count and channel interleaving over one single port
> for high-performance apps.
Variable channel count is something I'd like to see, but I'm very
sceptical about interleaved data in anything but very specialize
systems. (That is, not systems running anything like what we call
plugins.)
> Again the whole concept is so simple that "dumb" mono plugins
> only have to tell the host that they support only one input and one output.
> All you have to do is to add a couple of assignments in the descriptor()
> function and you are done.
Yes, but how often will it actually be usable without ripping the
interleaved data appart to connect it anywhere? It would save some
CPU for things like a modular version of ChannelStrip (between the
modules), but that's probably not enough to warrant a special API
extension for it.
//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 -'
This archive was generated by hypermail 2b28 : Sun Mar 26 2000 - 02:50:18 EET