Subject: Re: [linux-audio-dev] LADSPA GUI Issues
From: David Olofson (david_AT_gardena.net)
Date: Fri Mar 31 2000 - 06:19:47 EEST
On Thu, 30 Mar 2000, Kai Vehmanen wrote:
> On Thu, 30 Mar 2000, David Olofson wrote:
>
> >>> 1) How do hosts convert data when needed? (That is, if not
> >> They don't. This is why we have just a few format (32bit and 64bit
> >> float). You recompile, load another .so file, contact the plugin
> > Ok; maybe I've had to deal with too much closed source/proprietary
> > crap before I started to use a real OS, but this attitude worries me
>
> Hmm, here's my thoughts in a nutshell:
>
> - converting from format to another format is expensive
Yes.
> - it's very likely that either the host or the plugin
> is open-source (recompiling one of them is enough)
Not necessarilly true if you need to use more than one plugin at a
time, but hopefully, one can avoid depending on more than one closed
source plugin at a time.
> - if we want to support multiple formats, avoid conversions
> and avoid recompiling, either the host or the plugin will
> have to support multiple formats
The point is not to avoid conversions or to goin performance in mixed
format setups, but to allow the latter when needed. Considering the
plugin host daemon vs. multiple applications discussion, this is
pretty likely to happen unless *all* plugins are Open Source, or all
plugins use the same data format. If we're hoping for the latter to
work out, it's probably a better idea not to support anything but 32
bit floats at all in this API version, or at least strongly recommend
not using any other formats.
Hopefully, we actually know what is needed and how to do it when
users start asking for other formats than 32 bit floats.
> - we'd like to see lots of LASDSPA hosts and plugins
> (most linux audio apps should be able to host LADSPA
> plugins)
Yes. Hopefully, these plugins will port easily to any new API...
> ==> complexity is something we should avoid, even if this
> forces us to some compromises
Yep. This argument supports my late rediscovering that MuCoS should
be a separate/alternative API as well. A LADSPA plugin run() function
resembles the inner loop of a MuCoS plugin, and that's how it should
be done; MuCoS hosts will run (one or a chain of) LADSPA plugins
inside a MuCoS wrapper plugin. Of course, MuCoS plugins should be
written and optimized as MuCoS plugins for good performance.
> >> a good thing. If everything uses the same format, everything is simpler.
> > Yes. The world would be a lot simpler if all humans were alike as
> > well...
>
> Uhm, are you saying that we aren't? ;)
Well, I get the same kind of feeling after a look in the audio-dev
folder... But it might just be my imagination! ;-)
//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 : Fri Mar 31 2000 - 07:51:02 EEST