Subject: [linux-audio-dev] LADSPA v1 and LADSPA v2 thoughts
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Tue Mar 28 2000 - 20:27:25 EEST
Hi,
after reading all posts and thinking about the verious issues,
I came to the conclusion that LADSPA1 (float-only) as it is is
ok for an initial solution.
Assume LADSPA2 will contain features like the ones in my sample-code:
multi-datatype , indepentent input and output datatype , multichannel etc.
A LADSPA2 host, will easily be able to load LADSPA1 plugins too , since
it knows that it only supports float.
I agree too that the simple LADSPA1 design will not scare away
plugin developers, since there is no cryptic stuff in it.
I was worried about LADSPA2 hosts not being able to run LADSPA1 plugins,
but that is a non issue, because the load process and running process
remains basically the same.
some items to CHECK before releasing LADSPA1:
- API versioning, introduce a version field
a LADSPA2 host has to check the LADSPA version used by the plugin
before using it.
- maybe we should keep the size of LADSPA_Descriptor the same in
LADSPA1 and LADSPA2 to ease compatibility between the APIs.
- in my version of LADSPA, instantiate() has an InitParameters structure
instead of only the samplerate as in LADSPA1.
Maybe we could introduce InitParameters in LADSPA1 with only the
SampleRate field and padding zeros to accomodate future fields,
in order to keep the function prototypes coerent among v1 and v2.
- runAdd() .. this is still a candidate for LADSPA1 because, it increases
performance very much in some cases.
One could argue: why not leave it for LADSPA2 ?
No, because assume that we have a really nice binary-only plugin written
in LADSPA1, and now we want it to use in a high-performance enviroment
where all plugins make heavily use of runAdd().
In this case, the binary-only plugin , which does not support runAdd()
would cause a performance hit.
And since there are no multichannel issues in LADSPA1, a simple setGain()
for runAdd() would suffice completely.
- GUI Issues:
PortRangeHints look fine for simple automatic GUIs built by the host.
But there could be "complex" plugins which want to provide their own
GUI. Therefore my proposal is to add a new HINT type
for the PortRangeHintDescriptor:
LADSPA_HINT_CUSTOM_GUI , which informs the host that this value
can't be displayed using standard GUI elements, but would require
a custom GUI input. For example a FFT filter which expects 32 complex
numbers (real+imaginary) as input.
- VST1 plugins wrapped into LADSPA: (MANY want this)
I have to look again at the VST1 API but I think they have a parameter()
callback to inform the host when a parameter changes.
I already have a simple solution in mind which doesn't involve GUIs etc
and which doesn't give up RT capabilities etc. I will describe it
in 1-2 days when I have all elements toghether.
waiting for comments ....
Benno.
This archive was generated by hypermail 2b28 : Wed Mar 29 2000 - 01:58:32 EEST