Re: [LAD] preset saving in sessions
With the advent of NSM, there's a better chance than ever for autoloaded sessions when working. One of the challenges of autoswitching between sessions is loading presets for that session. In, for example LV2rack, it starts, but presets have to be loaded manually, after it gets going. Is there a mechanism for LV2rack, and other standalone plugin hosts, to have a preset automatically load with the selected preset for a session, when that session is selected? 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. Where would a call for an autoloaded session saved preset come from? The session manager, or LV2rack itself? To be clear, applications do have to be patched to support NSM. The same is true of XSM, LASH, and JACK-Session. The difference is that the NSM protocol provides much more information to all parties and is therefore far more useful. Unsupportive applications behave similar to LADISH level 0, where they can only be started and stopped. That being said, the changes required are about as complex as those required by LASH and JACK-Session, but provide greater functionality. The issue of presets is one I have been thinking about and am probably going to update the NSM API documentation soon with a recommendation. I believe that presets under session management should be true copies/transformations of state. Setting a preset should alter the parameters involved in such a way that the changes are completely and permanently stored in the application specific project file/directory--independent of whatever presets the particular user may have access to. Most sensible software already works this way, so it shouldn't be a problem to enforce. LV2rack seems like a good candidate for patching. That is, it is something which I might consider useful and has a fair amount of state. I'll look into patching it, or, if the developer would like to patch it themselves, I'd be happy to offer assistance. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] preset saving in sessions
On Sun, 2012-03-04 at 08:17 +, 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
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 +, 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
Re: [LAD] preset saving in sessions
On Sun, Mar 4, 2012 at 3:37 PM, J. Liles malnour...@gmail.com wrote: 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 its not always LV2 that is the cause of this. consider the SFZ file format. it refers to other audio samples. it doesn't require that the references use absolute paths, but they can. so now create a plugin that allows the user to alter what samples are used for various note numbers or velocity values or whatever (i.e. a reasonably capable sampler) and ask it to save its current state. it gives you an SFZ file to stash away in a location of the host's own choosing. but what do the contents refer to? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] preset saving in sessions
On Sun, 2012-03-04 at 12:37 -0800, J. Liles wrote: On Sun, Mar 4, 2012 at 9:38 AM, David Robillard d...@drobilla.net wrote: [...] 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. I agree. Some fancy automatic mechanism to resolve missing plugins somehow might be nice, but that's orthogonal. Plugin binaries definitely do not belong in saved sessions. (Plugins using files *whatsoever* should be discouraged, but sometimes it's truly necessary) 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. This is only true *sometimes*. If you are saving a session locally, sure, you don't want to copy everything it touches into the save directory (possibly many times). However, the ability to completely archive a session, including samples and such, is a very important ability. Sessions aren't very useful if I can't make one, send it to you, and have us collaborate. Or make one, archive it, and load it up later on some other machine and actually have it work. If you get hundreds of unresolved file references to mysterious paths on some other machine, the system has utterly failed to do its job. Put in other terms, the session shouldn't *always* be archived, but the ability to archive sessions is crucial. 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. In terms of the plugin interface, all that happens is the host gets the opportunity to map any paths the plugin saves to its state. This way, it can implement any behaviour. Symlinks just happen to be the best and simplest one, all things considered. Instead of inventing some new file format everyone has to deal with and erecting some bloated framework to accomplish all this, you just archive the thing and resolve symlinks. Good old fashioned tar can even do it (both full and shallow archival). It's also very convenient that what's going on is very clear at the file system level, you can see precisely what files are referred to just by looking at a directory listing, and you can even resolve broken links manually with generic tools (i.e. ln). All of this becomes a real nightmare if the paths are buried in some XML file, or whatever. I guess it's summed up nicely by the fact that you can do all of the following without any dependency on a particular API or file format whatsoever: * Report and/or resolve missing files in the session * Do a shallow archival of the session * Do a deep archival of the session which will load on other systems without any missing data * Do all of the above recursively (sessions within sessions) with zero additional effort Of course, this isn't mandated by LV2 or anything, but the friction you'd have to overcome to achieve the same with a bloated pile of unnecessary garbage is so massive it's the only realistic solution for plugins with files in hosts in session managers. It relieves the burden of session managers having to have an interface specifically for this and hosts having to implement it (which, even if you did, means you'd have to launch the host just to export an existing session). 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. This might be simple, but it might also be completely impossible. I agree it should be possible to implement this behaviour (to share lightweight sessions among people who do share a common set of data), but it also must be possible to do a true self-contained export. Luckily though, all of this boils down to a very simple requirement: the host must be given the opportunity to do whatever to paths. 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
Re: [LAD] preset saving in sessions
On Sun, 2012-03-04 at 16:17 -0500, Paul Davis wrote: On Sun, Mar 4, 2012 at 3:37 PM, J. Liles malnour...@gmail.com wrote: 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 its not always LV2 that is the cause of this. Well, LV2 is never the *cause* of this, it's an inherent problem to plugins that use files. consider the SFZ file format. it refers to other audio samples. it doesn't require that the references use absolute paths, but they can. so now create a plugin that allows the user to alter what samples are used for various note numbers or velocity values or whatever (i.e. a reasonably capable sampler) and ask it to save its current state. it gives you an SFZ file to stash away in a location of the host's own choosing. but what do the contents refer to? Yeah, this problem sucks. The only solution is for the plugin to map the paths inside that SFZ file. It is (inherently) necessary for the plugin to map *ALL* paths in its state for this to work. If they happen to be in some pre-existing file, well, that's probably going to be pretty annoying, but you have to map them all the same. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] preset saving in sessions
Am 4. März 2012 22:47 schrieb David Robillard d...@drobilla.net: On Sun, 2012-03-04 at 16:17 -0500, Paul Davis wrote: On Sun, Mar 4, 2012 at 3:37 PM, J. Liles malnour...@gmail.com wrote: consider the SFZ file format. it refers to other audio samples. it doesn't require that the references use absolute paths, but they can. so now create a plugin that allows the user to alter what samples are used for various note numbers or velocity values or whatever (i.e. a reasonably capable sampler) and ask it to save its current state. it gives you an SFZ file to stash away in a location of the host's own choosing. but what do the contents refer to? Yeah, this problem sucks. The only solution is for the plugin to map the paths inside that SFZ file. It is (inherently) necessary for the plugin to map *ALL* paths in its state for this to work. If they happen to be in some pre-existing file, well, that's probably going to be pretty annoying, but you have to map them all the same. For simplification, one could assume all samples had a common parent directory ? Then the user could simply re-locate that common parent directory, if the samples were not found ? example: /home /user /store /samples /shapewavs /sine.ogg moved to: /home /user /newplace /samples /shapewavs /sine.ogg common parent directory: samples/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] preset saving in sessions
On Sun, 2012-03-04 at 23:17 +0100, Emanuel Rumpf wrote: Am 4. März 2012 22:47 schrieb David Robillard d...@drobilla.net: On Sun, 2012-03-04 at 16:17 -0500, Paul Davis wrote: On Sun, Mar 4, 2012 at 3:37 PM, J. Liles malnour...@gmail.com wrote: consider the SFZ file format. it refers to other audio samples. it doesn't require that the references use absolute paths, but they can. [...] It is (inherently) necessary for the plugin to map *ALL* paths in its state for this to work. If they happen to be in some pre-existing file, well, that's probably going to be pretty annoying, but you have to map them all the same. For simplification, one could assume all samples had a common parent directory ? Unfortunate the SFZ file format does not have any such rule, so you can't make that assumption in general. Well... you can (on POSIX anyway), but in the worst case it might be the root, which means you end up with the entire file system in your session. Oops :) -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
