Subject: [linux-audio-dev] LAD(S)PA datatype-INDEPENDENT simple host released !
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sun Apr 02 2000 - 19:26:59 EEST
[ not sure if the message got lost in the mailinglist, since I got no copy
back by LAD, therefore I am resending the msg]
Hi,
I enhanced the LAD(S)PA sample host further, to do what some on this list were
dreaming about:
TOTAL DATATYPE INDEPENDENCY: (it took me only a few hours to implement it,
therefore it's nothing magic)
get it here:
http://www.linuxdj.com/ladspa/LADSPA-MUCOS04012000.tgz
try the demo, and look at applyplugin.c
the host can now load and process any plugin with any datatype, the only
condition which must be meet is that
one of the output datatypes of plugin K has to match one of the input datatypes
of plugin K+1.
THAT'S ALL !
Maarten, if you want to pass your famous spectral data across plugins, it's
just a implementation issue, the sample host above can handle it.
:-)
( in fact I forced the frist plugin's input and the last plugin's
output to be FLOAT32 in order to keep Richard's WAV reading and writing
routines the same.)
I added a few plugins:
- float2double: requires FLOAT32 (float) as input and outputs
FLOAT64(double), trivial to implement
-double2float: does the opposite of float2double: converts double to float
- filter64 : it's basically filter.c recompiled to use doubles instead of floats
now look at a sample session:
time ../bin/applyplugin -s 1 \
../snd/noise.wav /tmp/test.wav \
../plugins/filter.so lpf 3000 \
../plugins/delay.so simple_delay 1 0.2 \
../plugins/float2double.so float2double \
../plugins/filter64.so lpf 3000 \
../plugins/double2float.so double2float \
signal flow:
WAV_INPUT--float--> FILTER.SO --float-> DELAY.SO --
--float-->FLOAT2DOUBLE.SO--double->FILTER64.SO--double--
-->DOUBLE2FLOAT.SO--float-->WAV_OUTPUT
as you can see, filter64 works only with 'double' (64bit floating point),
therefore two converter plugins are needed.
The host automatically figures out the size in bytes of the biggest datatype,
using the DataTypeDescriptor.BitAlign field (basically the size of the datatype
expressed in bits), and then allocates the buffers accordingly.
Notice that almost all plugins which manage different datatypes at input and
output side do have the INPLACE_IS_BROKEN property set, since they need
different at input and output side in order to avoid overwriting values during
conversion. (to be more precise this is true when
sizeof(input_datatype) < sizeof(output_datatype) )
now look at at the output of the "applyplugin command above" :
first, the host sees if all datatypes are compatible between plugin's
inputs and outputs, and what the size of the largest datatype (in bytes) is.
finding maximum DataType size (BitAlign value) ....
DEBUG: matching output datatypes: output of plugin 0 with input of plugin 1
DEBUG: matching output datatype FOUND: 'FLOAT32' BitAlign=32
DEBUG: matching input datatypes: input of plugin 1 with output of plugin 0
DEBUG: matching input datatype FOUND: 'FLOAT32' BitAlign=32
DEBUG: matching output datatypes: output of plugin 1 with input of plugin 2
DEBUG: matching output datatype FOUND: 'FLOAT32' BitAlign=32
DEBUG: matching input datatypes: input of plugin 2 with output of plugin 1
DEBUG: matching input datatype FOUND: 'FLOAT32' BitAlign=32
DEBUG: matching output datatypes: output of plugin 2 with input of plugin 3
DEBUG: matching output datatype FOUND: 'FLOAT64' BitAlign=64
DEBUG: matching input datatypes: input of plugin 3 with output of plugin 2
DEBUG: matching input datatype FOUND: 'FLOAT64' BitAlign=64
DEBUG: matching output datatypes: output of plugin 3 with input of plugin 4
DEBUG: matching output datatype FOUND: 'FLOAT64' BitAlign=64
DEBUG: matching input datatypes: input of plugin 4 with output of plugin 3
DEBUG: matching input datatype FOUND: 'FLOAT64' BitAlign=64
DEBUG: done calculating. max BitAlign=64 bits, biggest datatype size in bytes=8
now comes buffer allocation: by default only one set of buffers is allocated but
if there are INPLACE_BROKEN plugins , additional buffers are needed:
(...)
DEBUG: matching output datatypes: output of plugin 2 with input of plugin 3
DEBUG: matching input datatype FOUND: 'FLOAT64'
WARNING: plugin 'Simple FLOAT32(float) to FLOAT64(double) converter' has INPLACE_IS_BROKEN, allocating more buffers .... MainBufferIndex=1
(...)
DEBUG: matching input datatypes: input of plugin 4 with output of plugin 3
DEBUG: matching input datatype FOUND: 'FLOAT64'
WARNING: plugin 'Simple FLOAT64(double) to FLOAT32(float) converter' has INPLACE_IS_BROKEN, allocating more buffers .... MainBufferIndex=2
As you can see 3 set of buffers are allocated because the float2double and
double2float plugins do not support INPLACE processing.
Notice that there is still a conceptual "bug" in my code, because the
instantiate function overwrites some function pointers in the Descriptor
structure. That means you can only have one instance per plugin,
(or multiple with the same datatype).
The solution is to move the function pointers to the Handle structure since
there is one Handle per instance. But that is trivial to do.
Anyway I like this system a lot , it has to be refined further, but it will
allow very flexible operations, with no sacrifice in speed, and no
"bloated" hosts.
What would be the ideal strategy for making the best of VST2.0 , LADSPA ,and
MUCOS (will contain my extensions) ?
Richard, Paul, David , others .... waiting for inputs.
PS: what I don't like from LADSPA1.0 :
Ports should encapsulate the RangeHints pointer, Names , flags, etc , to make
one unified structure , which is easier to manage than separate arrays of
structures,
as Roger Larsson pointed out.
Benno.
This archive was generated by hypermail 2b28 : Sun Apr 02 2000 - 18:55:38 EEST