Subject: Re: [linux-audio-dev] defending simplicity
From: David Olofson (david_AT_gardena.net)
Date: Thu Mar 30 2000 - 08:32:21 EEST
On Mon, 27 Mar 2000, Kai Vehmanen wrote:
> On Mon, 27 Mar 2000, Juhana Sadeharju wrote:
>
> > You define a new type 123. Your plug-ins knows that type and can
> > discuss together. You may help the engine by telling how much bytes
> > your type is.
>
> Hmm, we are not connecting plugins to each other. We are defining
> a standard API for a callback function that modifies an area of memory.
> The host calling this function must know the exact data format.
Only if the host doubles as a DSP engine.
> I think it's unrealistic to assume that the whole processing network
> (inputs, processors, outputs) is based on LADSPA-plugins.
It's unrealistic only if you can't do it because of plugin API
restrictions. With multiple data types, it's even a viable
alternative to a monolithic application with some plugin extension
capabilities.
> If we don't use a standard format, we'll end up in a situation where
> there are LADPSA-plugins for ecasound (STL-vectors of sample data),
> LADSPA plugins for Paul's latest Ardour version (26channel 24bit-in-32bit
> data), LASDPA plugins for aRts/MCOP, etc etc ... Yep, sure we have a standard
> plugin API, but most plugin-host combinations are incompatible.
This will happen only if all developers are insane. Hopefully, I and
the other multiple-format advocates are the craziest people around
here - the others will try to stick with one or two of the standard
formats rather than adding the list, ie the recommendation that
should be in the docs and headers.
> And 32bit vs 64bit vs 128bit is not an issue. You can just compile for
> multiple targets, without any changes in plugin or host code.
- You can't recompile closed source plugins, and
- you cannot count on all plugins working correctly with your
favourite data format. If you try to compile a 64 bit FFT
plugin as 32 bit, you'll get crap out of it, unless the coder
was wise enough to fix the data format of the internal work
variables.
//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 : Thu Mar 30 2000 - 13:27:06 EEST