[linux-audio-dev] Re: [jmax] Running a patch as a LADSPA plugin

[Francois Dechelle]

On Tue, 2003-03-18 at 10:36, Steve Harris wrote:

> 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.
> 
> > 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.

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.


>  
> > 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.

Too bad. Is there any trick to twist LADSPA plugins for that? 

François