[LAD] Interoperability between session management systems

Patrick Shirkey pshirkey at boosthardware.com
Sun Feb 24 21:04:23 UTC 2013

On Sun, February 24, 2013 6:05 am, David Robillard wrote:
> On Sat, 2013-02-23 at 17:01 +0100, Johannes Kroll wrote:
>> A couple of days ago, I tried out non-session-manager, and thought,
>> this is really nice. It really works in a practical, easy way.
>> Unfortunately the number of apps supporting non-session is quite small
>> (as is the case for *all* session management systems, AFAIK). There may
>> be "a complete audio studio" supporting non-session, from one choice of
>> sequencer to one synth to one sampler, but people like to use their
>> favorite software. You can't just say, "if you want to use a sequencer,
>> use X because it supports non-session". So its usefulness is limited.
>> However, many apps support one session management framework or the
>> other. So the obvious thing to do if you want to give people more
>> choices would be to create some kind of interoperability layer between
>> session management systems.
>> What do you think about this? Is there an effort for something like
>> this already underway? I personally think a good first step might be to
>> create some compatibility between non-session (because I like it) and
>> jack-session (because most people are using jack).
> 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.
> I like the lowest common denominator, and UNIXeyness, and zero
> imposition of syntax and so on, of this idea, but haven't really
> investigated it or done much of an implementation.
> Being based purely on classic UNIXisms (directory and a script that
> calls some utilities is all that's going on) is probably the only way to
> actually get everybody to agree on such a thing.  Standardization of
> such a spec would only involved command line utilities/arguments, paths,
> and environment variables.  Thanks to the shebang mechanism, it would be
> language agnostic as well.
> Personally I have no plans to prioritize this, but I think it's an
> interesting area to explore.

Why do applications need to support a specific session manager? The
session manager just calls the JACK API to notify a client app that an
update is required to the internal state.

What else is there to bother with on the application side?

Patrick Shirkey
Boost Hardware Ltd

More information about the Linux-audio-dev mailing list