Re: [linux-audio-dev] LADSPA GUI Issues

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] LADSPA GUI Issues
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Fri Mar 31 2000 - 04:00:49 EEST


On Thu, 30 Mar 2000, Erik Steffl wrote:

>> - converting from format to another format is expensive
>> - it's very likely that either the host or the plugin
>> is open-source (recompiling one of them is enough)
> !!! recompiling as a way to get flexibility is WRONG. completely
> wrong. and not possible in all cases.

We are talking about mono audio streams represented by floating
point numbers. For transfering this kind data, there aren't
that many choices. It's either 32bit, 64bit, 128bit, or Nbit. As far
as I see, this usually isn't a plugin specific choice. If I need 64bit
(for instance a 64bit platform), I want all hosts and plugins to
use this precision. The data format is still floating-point numbers.
And note that internally plugins can use whatever format they want.
Floats are just used to represent the shared memory area.

> if you want to use one plugin that's just 8 bit and produces e.g. blue
> dots on the screen based on the low frequency amplitude (this might
> serve as kind of metronome or something) [8 bit signal for that might be
> plenty enough and let's say it's binary only plugin] you will do all
> your sound processing in 8 bits???

Maybe you should check the archives. We've been through this many, many
times. I'm not saying that all processing in the world should be done
with 32bit floats. I'm saying that at the moment we have n+1 app-specific
plugin APIs. To change this situation and start reusing dsp-code, we
need to start from something. Something that people will use. You can
do the above using floats. If the performance difference between 8bit
and 32bit-float implementations is that important to you, using a plugin
API might not be the best choice for you.

> also, if you have binary only plugin that's uses 32 bit data and
> binary only that uses 64 bit data how exactly do you recompile that host
> so that it can use both?

Well, as I've said before, the (closed-source) plugin distributor should
offer multiple versions.

> regarding data types: it is (hopefully) possible to describe them by
> parameters, so that the host does not have to have specifically coded
> conversion from each type to each another type but simply have algorithm

This is just what Benno suggested a few days ago. And no, it's not
a bad design. It's something that most of us do in our own apps. Of
course we'd all like to have an extremely generic plugin API, lots of
generic hosts and huge library of plugins, but at the moment we have none
of this.

-- 
Kai Vehmanen <k_AT_eca.cx> ---------------- CS, University of Turku .
 . audio software for linux ...	http://www.eca.cx 		 .
 . armchair-tunes mp3/wav/ra .. http://www.wakkanet.fi/sculpcave .


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Mar 31 2000 - 12:30:31 EEST