18 Mar
2003
18 Mar
'03
5:45 a.m.
[This is a conversation Francois and I have been having this morning.
There is a general problem with LADSPA wrapper plugins that create
plugins from other sources. Its not possible for them to pick unique IDs
as they dont know what has been assigned and what hasn't]
On Tue, Mar 18, 2003 at 10:14:44AM +0100, Francois Dechelle 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.
That reminds
me, there was another issue that Thomas raised, theres
currently no way to create a one-time unique LADSPA id, which I guess you
would need for this to work reliably.
Yes, it is something that I need. The problem is that the jmaxladspa
plugin is not a unique plugin: the number of plugins it defines is
variable (it is the number of .jmax files that are in LADSPA_PATH
directories).
A temporary solution would be to allocate to the jMax plugin a range of
unique IDs and that no more than this range patches can be loaded. What
do you think about it? 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.
BTW, do you think we should discuss this on jMax
mailing list or on
linux-audio-dev?
Yes, both probably, but I've forgotten what email address I subscribed to
the jMax list with. I guess I should resubscribe. I'l CC this to l-a-d in
the meantime.
- Steve
18 Mar
18 Mar
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.
7:55 a.m.
On Tue, Mar 18, 2003 at 12:04:46 +0100, Francois Dechelle wrote:
Yes, but the ID number would be created from a hash of the unqiue
identifier (eg. a URI), so it would be consistant between sessions.
Too bad. Is there any trick to twist LADSPA plugins for that?
Not cleanly. You do can hacks with /tmp files and control values, but they
are messy.
- Steve
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. 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.
8:40 a.m.
On Tue, 2003-03-18 at 12:46, Steve Harris wrote:
Yes, but the ID number would be created from a hash of
the unqiue
identifier (eg. a URI), so it would be consistant between sessions.
What would be this unique identifier in the case of the jMax plugin? The
full path name?
Anyhow, this would be for a new version of LADSPA, I guess. What should
I do for now: use a range of IDs that will be reserved for jMax plugin?
The plugin will then allocate IDs for each patch, but as you noticed,
this set may have changed when you reload .
Not cleanly. You do can hacks with /tmp files and
control values, but they
are messy.
May be use an environment variable to tell in which directory to look
for the files, and a control value to give the file number in this
directory ?
François
10:47 a.m.
On Tue, Mar 18, 2003 at 01:31:28 +0100, Francois Dechelle wrote:
On Tue, 2003-03-18 at 12:46, Steve Harris wrote:
Yeah, could be file:///path/to/jmax/file or similar.
Yes, but the ID number would be created from a
hash of the unqiue
identifier (eg. a URI), so it would be consistant between sessions.
What would be this unique identifier in the case of the jMax plugin? The
full path name? Anyhow, this would be for a new version of LADSPA, I
guess. What should
I do for now: use a range of IDs that will be reserved for jMax plugin?
The plugin will then allocate IDs for each patch, but as you noticed,
this set may have changed when you reload .
I think environment variables are a bit too problematic, thier not private
to individual plugins, but could could create /known/path/file-<control val
a> then look on line <control val b> for the real filename.
The /known/path could be specified with an env var.
All this stuff is pretty kludgy though, to get round the fact that you're
trying to use LADSPA for something its not intended for.
- Steve
Not cleanly. You do can hacks with /tmp files and
control values, but they
are messy.
May be use an environment variable to tell in which directory to look
for the files, and a control value to give the file number in this
directory ? 
21 Mar
21 Mar
7:41 p.m.
On Tue, Mar 18, 2003 at 12:04:46PM +0100, Francois Dechelle wrote:
On Tue, 2003-03-18 at 10:36, Steve Harris wrote:
galan saves against the label.
I wanted to change this to the UID after thinking the label was not
unique. But if i get this right the label is unique. And then i will
leave it like it is.
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? 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.
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.
Too bad. Is there any trick to twist LADSPA plugins for that?
you could stream it into an audio input... but this is really ugly...
i would write a string event to audio converter if you used this
approach.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
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. 
22 Mar
22 Mar
1:37 a.m.
On Fri, 2003-03-21 at 14:36, torbenh(a)gmx.de wrote:
Ardour saves using the ID.
Taybin
On Tue, Mar 18, 2003 at 12:04:46PM +0100, Francois
Dechelle wrote:
What is the
usual strategy for LADSPA hosts that save their state? Do
they store only the ID or also the label?
galan saves against the label.
I wanted to change this to the UID after thinking the label was not
unique. But if i get this right the label is unique. And then i will
leave it like it is.
4:59 a.m.
On Fri, Mar 21, 2003 at 08:36:57 +0100, torbenh(a)gmx.de wrote:
galan saves against the label.
I wanted to change this to the UID after thinking the label was not
unique. But if i get this right the label is unique. And then i will
leave it like it is.
The label is not unique.
Making it a requirement that the id+label be unique could be one way
forward, but it will cause problems with some existing hosts.
- Steve
23 Mar
23 Mar
3:16 p.m.
On Sat, Mar 22, 2003 at 08:50:54AM +0000, Steve Harris wrote:
On Fri, Mar 21, 2003 at 08:36:57 +0100, torbenh(a)gmx.de
wrote:
ok... galan-0.2.15 will also save the ID and use it for loading.
holy shit... i must make a significant change to the loading and
saving. The load save tag in galan is the same as the component label.
galan saves against the label.
I wanted to change this to the UID after thinking the label was not
unique. But if i get this right the label is unique. And then i will
leave it like it is.
The label is not unique.
Making it a requirement that the id+label be unique could be one way
forward, but it will cause problems with some existing hosts.
- Steve
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
8009
days inactive
8014
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
Francois Dechelle -
Steve Harris -
Taybin -
torbenh＠gmx.de