[LAD] Interoperability between session management systems

hermann meyer brummer- at web.de
Sun Feb 24 04:09:19 UTC 2013

Am 24.02.2013 04:15, schrieb J. Liles:
> On Sat, Feb 23, 2013 at 6:34 PM, Johannes Kroll <jkroll at lavabit.com 
> <mailto:jkroll at lavabit.com>> wrote:
>     On Sat, 23 Feb 2013 17:28:49 -0800
>     "J. Liles" <malnourite at gmail.com <mailto:malnourite at gmail.com>> wrote:
>     > All of the existing session management protocols have inherent
>     limitations
>     > which I was attempting to avoid by creating NSM. Nedko and I
>     have discussed
>     > including NSM protocol support in LADISH, which would be kind of
>     like what
>     > you're talking about, but the problem remains that the whole
>     would be a
>     > lowest-common-denominator of functionality. Now, if jack session
>     and LASH
>     > and LADISH level 1 applications eventually fade out and move to
>     the NSM
>     > protocol, then maybe that's OK. But in the meantime it's not
>     going to be as
>     > functional as using pure NSM.
>     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
>     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'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!
I stated it out already in a other thread: without ever been released as 
NSM (means available as tarball, or what ever, with ONLY NSM included), 
I wouldn't support it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20130224/b37edef5/attachment.html>

More information about the Linux-audio-dev mailing list