Re: [LAD] preset saving in sessions

From: J. Liles <malnourite@email-addr-hidden>
Date: Sun Mar 04 2012 - 11:58:14 EET

> 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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Mar 4 12:15:01 2012

This archive was generated by hypermail 2.1.8 : Sun Mar 04 2012 - 12:15:01 EET