[LAD] Interoperability between session management systems

Alex Stone alextone1099 at gmail.com
Sat Feb 23 22:44:36 UTC 2013

On 23 February 2013 23:22, Nils Gey <ich at nilsgey.de> wrote:
> On Sat, 23 Feb 2013 14:05:07 -0500
> David Robillard <d at drobilla.net> wrote:
> > I was tinkering with saving sessions in a format that is just a
> > directory with a shell script with a standard name (and perhaps some
> > standard arguments) which you call to restore or do other things.
> >
> > Not sure if that's a really feasible solution in general, but it's
> > basically the only way to save sessions in a way that don't require a
> > specific session manager to load, and doesn't impose any file formats.
> >
> > Actually being able to restore sessions decently from a script requires
> > a few more sophisticated jack command line utilities (like a
> > jack_connect that can wait for clients and so on), but those are useful
> > anyway.
> Just a quick thought: How do you get the programs to save their state/file?
> Does this not require at least some incoming message handling by the individual programs?
> Nils
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

As a user of NSM, and from that user perspective, it does what it says
on the tin. It's user friendly, and helps administer the process of
starting up my large sessions with no rocket science involved.

Given the strong wills, and previous scorch marks in the ML about
session management, i have no desire to light a match here, but for
the simple task of starting a succession of apps in a session, NSM
does its job well, imho.

How much code is required in apps to enable them for NSM use?

Is there an appetite for at least one session management app that does
the simple stuff well that users can become familiar with as a
"linuxaudio" basic default, as a "unified" community protocol
agreement, without descending into hades and a flame war, in the
interest of taking the community forward, and giving users a better


More information about the Linux-audio-dev mailing list