18 Mar
2003
18 Mar
'03
7:13 a.m.
On Tue, 2003-03-18 at 10:36, Steve Harris wrote:
Too bad. Is there any trick to twist LADSPA plugins for that?
François
Thats OK as a quick fix, but it doesn't solve the
broader problem, if you
save state from a host using jMax LADSPA plugins then it wont necceserily
be the same set when you reload.
I think LADSPA needs self assigned ID's, if the UID space were bigger we
could just reseve the top bit for self assigned stuff and hash unique
strings to fill it, but as its only 32bits thats not enough space.
In any case, hosts that save the ID cannot restore the plugin settings
correctly, if the ID is assigned dynamically.
Currently, in the jMax LADSPA plugin, the label is the basename of the
patch file. This is clearly unique.
What is the usual strategy for LADSPA hosts that save their state? Do
they store only the ID or also the label?
Also, does the UID really need to be unique? If not, one UID for jMax
could be enough. Different plugins will differ by their label.
Apart from this solution, I don't see how to
do it.
Agreed, without a change to LADSPA I dont think its possible.
One solution could be to use a reserved ID range to flag that the ID isn't
globally unique, but the label string (not name) is, so hosts should save
state aginst the label not the ID. It has very dodgy semantics though.
A better solution would be to expand the ID space to 64bits, and reserve
the top bit's worth, which is plenty, but will break binary compatibility
of course. Another question: is there a plan to get plugin
port values that are not
floats? More precisely, I am thinking of transforming a patch that does
granular synthesis into a plugin. But this patch needs a sound file
name. How can I pass it to the LADSPA plugin?
You can't. I think this is thought to be outside the remit of LADSPA.