Subject: Re: [linux-audio-dev] LADSPA with dynamic datatype and multichannelsupport released !!
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Tue Mar 28 2000 - 01:02:09 EEST
On Mon, 27 Mar 2000, Erik Steffl wrote:
> Benno Senoner wrote:
> ...
> >> - plugins can support DIFFERENT datatypes for input and outputs.
> > The restriction is that you can have only one input datatype and one output
> > datype.
> > For example if you set input datatype = float and output datatype = double
> > the both input CONTROL ports and input AUDIO ports have to use the float
> > type, while output CONTROL ports and output AUDIO ports have to use double.
>
> this does not make sense at all. I mean, you either cros the street or
> don't cross the street but you don't stand in the middle... the datatype
> is a property of port, not property of plugin.
This was only a sample implementation, in order to show what can be done.
But since control ports are going to interact with the actual audio data, to me
it makes sense use the same datatype as the audio data.
A filter using doubles , should have the cut-off fequency expressed in
doubles too , in order to allow higher precision.
Anyway it's not a big deal to decouple the datatypes, the drawback is that
the host and plugin code get more complicated. The host has to make
the "right" choice when instantiating / connecting plugins.
One way to make ALL ports independent would be to add a
DataTypeDescriptor to each port and then let the host choose the
desired type.
But then in the multichannel case weird things could happen:
eg. : a host loads a stereo reverb, with two audio output ports
A and B.
The host requests the float datatype for port A and the double datatype
for port B. What to do now ?
We need some way to "tie" datatypes together,
so that if we choose float on the audio outs , ALL audio outs will
use this datatype.
But this port-independency sounds interesting, now that we have
the DataType descriptors. :-)
>
> > Allowing per-port datatype would make things much more complicated for host
> > and plugins, since our goal here is audio streaming not events.
>
> I think that having each port completely independent entity (too bad
> this is not C++) makes it easier, not harder. you know that you can do
> certain things with port... why should the plugin be important? I mean
> you should be able to the same things with port in plugin and in host
> (and in host you definitely don't want to restrict to one type of data
> for all ports). divide et impera (hope I've got spelling right).
I am changingmy mind here, you convinced me :-)
>
> > In the case of a plugin supporting multiple datatypes ,
> > since the datatype is passed to the instantiate function, some of the
> > functionpointer assignments have to be moved from the descriptor()
> > function to the instantiate() function since these are datatype dependent.
> > eg. a plugin supporting float and double would have two run() functions
> > run32() and run64() the Descriptor->run pointer would be assigned based
> > on the datatype passed to the instantiate function.
> > It's really easy to add a new datatype to a plugin.
>
> ??? as I see it the datatype is a characteristic of a port. all data
> description/definition should be in port (obtainable using the port
> descriptor only). the plugin should be close to not caring about the
> data-types (other then it has to process the data:-)
This is not trivial to solve, since we must first query the datatype
"capabilities" and then telll the plugin which one we want to use.
cheers,
Benno.
This archive was generated by hypermail 2b28 : Tue Mar 28 2000 - 01:49:52 EEST