On Sun, Mar 4, 2012 at 9:38 AM, David Robillard <[email protected]> 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
