Re: [LAD] preset saving in sessions

On Sun, Mar 4, 2012 at 9:38 AM, David Robillard <d@drobilla.net> wrote:
> On Sun, 2012-03-04 at 08:17 +0000, parched2099 wrote:
> [...]
>> An example is lv2rack with the IR lv2 plugin, which i've been testing
>> in NSM. LV2rack comes up ok, but the preset i've built for a specific
>> session doesn't automatically load. I assume this is the case when using
>> something like LV2rack in other session managers too.
>
> It should be noted that IR does some terrible kludges for saving state
> that make it impossible to store its state portably (it saves to a
> config file in a location unknown to the host and saves a hash into that
> file across several float control ports).
>
> However, the new LV2 state stuff is specifically designed to allow
> self-contained archival/export with any session manager[1].  Hopefully a
> future version of IR will move to it.  I don't know anything about NSM's
> facilities for export/archival, though.
>
> -dr
>
> [1] My preferred implementation is using symlinks to refer to external
> files, so any tool, even tar -h, can archive correctly.  KISS.
>

We must remember not to take this to a level of absurdity. For
instance, I don't believe that it is necessary to, for example,
copy/symlink LADSPA or LV2 plugin binaries themselves into a session.
The data is that the user selected such-and-such plugin. The plugin
can be expected to exist on the same system at another time and on
other systems. If it doesn't exist, it can be made to. Seems to go
without saying that programs which rely on plugins should not fail
horribly when one is missing, but should instead display enough
information to the user for them to be able to fix the problem.
Perhaps it needs saying anyway, though. This doesn't just apply to
plugins, but to soundfonts, generic sample libraries, etc. What should
be stored in the session is only what is specific to the session, and
that sometimes includes a selection between generic external entities.
Parameter presets are another matter, however, because they are often
not generic but are personal libraries of saved preferences which
cannot be expected to be aquirable on another system. This is why when
presets are involved, all the changes that a preset makes to the
parameters should be stored in the session.

If you use symlinks to cover the gray-area case of a non-generic
llibrary of impulse waveforms, that's fine and it would work for
archiving, but the point remains that if you don't create the symlink
and I attempt to load a copy of the session in a different
environment, I would expect to be told by the software what exactly is
missing. Obviously, solving the problem is as simple as going back to
the creator of the session and saying "Hey, I need this external
object in order to fully load your session."

BTW, I don't know if LV2 supports this, but if it allows plugins to
*SAVE* non-generic (that is to say, session specific) data wherever
they want on the filesystem, then that, IMHO, is badly broken. There
may be nothing technical that can be done about it, but you should at
the very least be able to point at a section of the API document and
say to the developer of such a plugin: Fix it, it's broken.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Mar 5 00:15:02 2012