[LAD] Interoperability between session management systems

David Robillard d at drobilla.net
Sat Feb 23 19:05:07 UTC 2013

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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20130223/ebb6ae18/attachment.pgp>

More information about the Linux-audio-dev mailing list