Re: [LAD] preset saving in sessions

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: David Robillard <d@...>
Cc: lad <linux-audio-dev@...>
Date: Sunday, March 4, 2012 - 8:37 pm

On Sun, Mar 4, 2012 at 9:38 AM, David Robillard wrote:

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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] preset saving in sessions, parched2099, (Sun Mar 4, 8:18 am)
Re: [LAD] preset saving in sessions, David Robillard, (Sun Mar 4, 5:38 pm)
Re: [LAD] preset saving in sessions, J. Liles, (Sun Mar 4, 8:37 pm)
Re: [LAD] preset saving in sessions, David Robillard, (Sun Mar 4, 9:29 pm)
Re: [LAD] preset saving in sessions, Paul Davis, (Sun Mar 4, 9:17 pm)
Re: [LAD] preset saving in sessions, David Robillard, (Sun Mar 4, 9:47 pm)
Re: [LAD] preset saving in sessions, Emanuel Rumpf, (Sun Mar 4, 10:17 pm)
Re: [LAD] preset saving in sessions, David Robillard, (Sun Mar 4, 10:32 pm)
Re: [LAD] preset saving in sessions, J. Liles, (Sun Mar 4, 9:58 am)