> 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
