23 Nov
2011
23 Nov
'11
8:26 p.m.
Here is the current version of the LV2 state extension, which defines
the model for plugin state, and a mechanism for saving and restoring it:
http://lv2plug.in/ns/ext/state
It's time to tag this one as stable, unless anyone can see any issues
(i.e. speak now, or forever hold your peace). If anyone has the time to
give it a quick read-through, feedback would be appreciated. I have
done a lot of work on the documentation lately, hopefully everything
should be clear.
This is currently implemented in Ardour 3 SVN, QTractor SVN, and a patch
for LinuxSampler SVN is available here:
http://drobilla.net/files/linuxsampler_lv2_state_0_4.diff
Thanks,
-dr
24 Nov
24 Nov
8:14 a.m.
New subject: [Devel] RFC: LV2 state
Hi,
My understanding of the underlying system is (currently) minimal, but the
documentation & code examples are definitely a great aid in understanding.
That's all I can say really!
-H
1:45 p.m.
Excerpts from David Robillard's message of 2011-11-23 20:26:49 +0100:
Here is the current version of the LV2 state
extension, which defines
the model for plugin state, and a mechanism for saving and restoring it:
http://lv2plug.in/ns/ext/state
It's time to tag this one as stable, unless anyone can see any issues
(i.e. speak now, or forever hold your peace). If anyone has the time to
give it a quick read-through, feedback would be appreciated. I have
done a lot of work on the documentation lately, hopefully everything
should be clear.
This is currently implemented in Ardour 3 SVN, QTractor SVN, and a patch
for LinuxSampler SVN is available here:
http://drobilla.net/files/linuxsampler_lv2_state_0_4.diff
Thanks,
-dr
The obvious question is: are there plugins where the state is not
completely described by their port values? I guess Rudolf 556 could be
such a thing. Any lv2 sampler would likely need to store paths and
wouldn't usually expose them (I guess). They'd simply need a different
extension. The question is whether there are many such cases in
existence.
Also regarding paths, what about windows paths and stuff like that? As
far as I understand the extension, the plugin stores any kind of path,
a host would need to handle the conversion from one path format to
another, correct?
I'm pretty much talking out of my arse here.. just to break the silence
:)
Regards,
Philipp
6:27 p.m.
On Thu, 2011-11-24 at 13:45 +0100, Philipp Überbacher wrote:
Excerpts from David Robillard's message of
2011-11-23 20:26:49 +0100:
> Here is the current version of the LV2 state extension, which defines
> the model for plugin state, and a mechanism for saving and restoring it:
>
> http://lv2plug.in/ns/ext/state
[...]
The obvious question is: are there plugins where the
state is not
completely described by their port values? I guess Rudolf 556 could be
such a thing. Any lv2 sampler would likely need to store paths and
wouldn't usually expose them (I guess). They'd simply need a different
extension. The question is whether there are many such cases in
existence.
... hm? That is the entire point of this extension.
From the opening paragraph:
The intention is for a plugin instance's state to be completely
described by port values (as with all LV2 plugins) *** and a simple
dictionary ***.
An extension is not needed for storing port values, hosts already have
access to those.
Also regarding paths, what about windows paths and
stuff like that? As
far as I understand the extension, the plugin stores any kind of path,
a host would need to handle the conversion from one path format to
another, correct?
I'm pretty much talking out of my arse here.. just to break the silence
:)
The host gets the opportunity to map paths in any way it pleases. You
can leave them be, map them to indexes into a table of actual file
paths, etc. Sessions that contain absolute paths aren't portable to
other system anyway, since the files referred to might not be there on
somebody else's computer, even if they are running the same operating
system.
Ardour uses this facility to create symbolic links in the plugin's state
directory that point to the absolute path. e.g.
/mysession/plugins/123/sample.wav -> /home/whoever/samples/sample.wav
The nice thing about this is that any stupid tool, like tar, can be used
to archive and distribute self-contained sessions. It's also easy to
see what went wrong and fix it manually in the shell or file manager (If
you moved your samples directory, for example). I recommend this
strategy to all plugins and hosts, having absolute paths buried in some
file in who knows what syntax is evil, particularly considering the fact
that we have session storage for apps as well.
-dr
4971
days inactive
4972
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
3 participants
participants (3)
-
David Robillard -
Harry van Haaren -
Philipp Überbacher