24 Feb
2013
24 Feb
'13
10:04 p.m.
On Sun, February 24, 2013 6:05 am, David Robillard wrote:
On Sat, 2013-02-23 at 17:01 +0100, Johannes Kroll
wrote:
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
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.