Subject: Re: [linux-audio-dev] LADSPA Version 1 , supporting an arbitrary number of datatypes
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Mar 23 2000 - 15:49:56 EET
I've looked at the ladspa samples,
quite neat.
:-)
a few small suggestions:
I would use typedefs instead of directly refering to stucts into LADSPA code.
in your code for example you do:
calloc(4, sizeof(struct LADSPA_PortRangeHint)));
I don't like the struct statement very much , since should the type someday
change to a non struct type (an int for example) , if would require to rewrite
existing code.
why not directly use typedef ?
like
typedef struct {
LADSPA_PortRangeHintDescriptor HintDescriptor;
LADSPA_Data LowerBound;
LADSPA_Data UpperBound;
}; LADSPA_PortRangeHint;
I use typedef all the time in my code, and feel much more confortable than
using structs, since it makes the code more readable and simplifies some things
like sizeof(yourdatatype)) instead of using sizeof(struct yourstruct))
2)
You should add an "unit" field so that the host can use this for displaying
purposes.
ie: if the delay is in msec , the unit string should return "ms" or "msec" so
that the host can display the unit on the slider/knob etc.
next
> 3. runAdding() support is not included. I'm still not 100% sure about
> this, but I'm a little more sure than previously. It seems that to make
> runAdding() useful it is necessary to include some kind of setGain()
> mechanism.
exactly, setGain() and getGain() will be sufficient to allow a flexible and
efficient adding method.
As for the 64bit FP support issue, I agree with David:
it would be very simple to add a datatype field to the port,
so that the host can check the type and act accordingly.
the run() , instantiate() etc functions would become a arrays of functions.
ie: a run() for each datatype
NumDataTypes = number of supported datatypes ( normally 1 , = 32bit float)
let the plugin complie a datatype array: like
datatypes[0] = LADSPA_DATATYPE_FLOAT32;
datatypes[1] = LADSPA_DATATYPE_FLOAT64;
datatypes[2] = LADSPA_DATATYPE_SINT16 (signed 16bit int)
etc.
now
run[0] would be the run() function which handles float32 format
run[1] the one which handles double (64bit float)
run[2] the one which handles 16bit signed integer
same for instantiate() and other type dependent functions
note that it is not mandatory that run[0] always handles the 32bit float.
for example if you want a 16bit-int only plugin
you set
NumDataTypes=1;
datatypes[0]=LADSPA_DATATYPE_SINT16;
and then set run[0] to the run_sint16() function
same applies to instantiate() and all other functions ( instantiate[0] set to
instantiate_sint16() etc)
As you see the programming overhead when supporting only the float datatype
over plain LADSPA is really tiny:
-- set NumDataTypes=1 alloc the types array , and the function arrays ( run[] , instantiate[] etc) set datatypes[0]=LADSPA_DATATYPE_FLOAT32 --simple hosts , designed for 32bit float only operation, will simply refuse to run plugins which do not support this datatype, as discussed in our previous mails.
With this extension , we are not bounded to 32bit or 64bit floats, but can use support an arbitrary number of datatypes without breaking binary compatibility with 32bit-only hosts/plugins.
If then a complex host will allow the mixing of different plugins, it has to do the conversion into the host code.
I think LADSPA + the above extension + runAdd() would be really nice , since it covers (excluding the event system) almost all our present and future plugin API needs. (David , your thoughts ?)
comments ?
(I am already hearing Richard saying "too complex", but from a plugin developer POW I have no big concerns about adding a couple of statements during the init phase)
Notice that with the system above, if a plugin supports multiple datatypes and a host uses only one of the datatype, the allocated memory and ressources will still be the same as in the float-only case. (except for the size of the plugin code, which will be a little bigger since some functions ( like run() have to be present for each datatype)
BTW: does support VST2 audio datatypes other than float ?
Benno.
This archive was generated by hypermail 2b28 : Thu Mar 23 2000 - 20:10:11 EET