[LAD] Interoperability between session management systems
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
> 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?
Boost Hardware Ltd
More information about the Linux-audio-dev