Re: [LAD] Interoperability between session management systems

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Johannes Kroll <jkroll@...>
Cc: <linux-audio-dev@...>
Date: Sunday, February 24, 2013 - 3:15 am

--047d7b16014969d6d104d66fd515
Content-Type: text/plain; charset=UTF-8

On Sat, Feb 23, 2013 at 6:34 PM, Johannes Kroll wrote:

> On Sat, 23 Feb 2013 17:28:49 -0800

I'm not starting a war. Many of the other SM protocols were designed with
full knowledge of their limitations and compromises (that is to say, the
authors don't believe they are the best solution by any means, just a
workable one). In fact, the differences between the different SM protocols
are great, and in the case of NSM even greater. Drobilla, with mention of
shell scripts, was speaking only of a session disk format that could used
to port existing sessions from one SM to another. If we add NSM support to
LADISH, that will be exactly what you desire. One SM front end that
supports every extant protocol. However, I believe this will hardly make
the situation any easier on the *user* than it is now (and since when are
people happy with LASH etc?). LASH, jack-session and LADISH Level 1 are
extremely limited, and, IMHO inadequate protocols. Continuing support for
them does nothing to enhance the user experience. And it isn't as if we're
talking about 100s of client applications here, there are only a handful
that support any kind of SM protocol period. I may have the desire to patch
everything to support NSM, but what I do not have is the time (and the time
I might spend adding NSM support to LADISH might better be spent converting
jack-session and LASH clients over to NSM). In any case, patching will do
far more good than talking!

--047d7b16014969d6d104d66fd515
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 23, 2013 at 6:34 PM, Johanne=
s Kroll <jkroll@lavabit.com> wrote:
On Sat, 23 Feb 2013 17:28:49 -0800
"J. Liles" <malnourite=
@gmail.com
> wrote:

> All of the existing session management protocols have inherent limitat=
ions

ussed
what
be a
ASH
M
oing to be as

Please, don't turn this into a "which session manager is the=
best" war,
that's not what I intended. Surely each coder thinks *their* session
manager is the best one, why else would they have written it. In
reality every SM has their strengths and weaknesses I guess. (For
example I noticed that NSM, which I otherwise like, can't restore Jack<=
br>
connections without an external tool like jack_patch - and with the
tool, it doesn't seem to restore MIDI connections).

About shell scripts (David): that sounds like the lowest common
denominator approach, and while it's neat and UNIXy and everything,
unless I misunderstood, writing shell scripts to start apps is what I
can do anyway, without any session manager. Also, I think the ability
to tell apps to save state while they are running is important, and
shell scripts can't do that.

I would hope that something more than the lowest common denominator
approach would be possible. As I understand it, all SM systems do the
following, in one way or the other:

1) start apps with a saved state (may be implemented using 2)
2) tell running apps to load their state from a given session
3) tell apps to save their state to a given session
4) possibly restore JACK and alsamidi connections
5) possibly implement parts of the session loading and saving (this
might be completely up to the apps)

If that's basically what SMs do, it should be possible to create an
interoperability layer (*NOT* a new protocol!) that talks the
existing protocols and does the necessary things. There might be
tradeoffs, when one SM system has less functionality as the other, but
that would hopefully only affect the apps using that SM system, not the
others. So it would not be "lowest common denominator".

If the differences between SMs are that great that doing this isn't
possible at all, that would be sad, because I don't really see any SM
becoming the defacto standard any time soon.I&#39=
;m not starting a war. Many of the other SM protocols were designed with fu=
ll knowledge of their limitations and compromises (that is to say, the auth=
ors don't believe they are the best solution by any means, just a worka=
ble one). In fact, the differences between the different SM protocols are g=
reat, and in the case of NSM even greater. Drobilla, with mention of shell =
scripts, was speaking only of a session disk format that could used to port=
existing sessions from one SM to another. If we add NSM support to LADISH,=
that will be exactly what you desire. One SM front end that supports every=
extant protocol. However, I believe this will hardly make the situation an=
y easier on the *user* than it is now (and since when are people happy with=
LASH etc?). LASH, jack-session and LADISH Level 1 are extremely limited, a=
nd, IMHO inadequate protocols. Continuing support for them does nothing to =
enhance the user experience. And it isn't as if we're talking about=
100s of client applications here, there are only a handful that support an=
y kind of SM protocol period. I may have the desire to patch everything to =
support NSM, but what I do not have is the time (and the time I might spend=
adding NSM support to LADISH might better be spent converting jack-session=
and LASH clients over to NSM). In any case, patching will do far more good=
than talking!

--047d7b16014969d6d104d66fd515--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] Interoperability between session management systems, Johannes Kroll, (Sat Feb 23, 4:01 pm)
Re: [LAD] Interoperability between session management systems, David Robillard, (Sat Feb 23, 11:36 pm)
Re: [LAD] Interoperability between session management systems, David Robillard, (Sat Feb 23, 11:45 pm)
Re: [LAD] Interoperability between session management systems, J. Liles, (Sun Feb 24, 3:15 am)
Re: [LAD] Interoperability between session management systems, Roy Vegard Ovesen, (Sun Feb 24, 10:58 am)