Re: [LAD] Interoperability between session management systems

Am 24.02.2013 04:15, schrieb J. Liles:
>
>
> On Sat, Feb 23, 2013 at 6:34 PM, Johannes Kroll <jkroll@email-addr-hidden
> <mailto:jkroll@email-addr-hidden>> wrote:
>
> On Sat, 23 Feb 2013 17:28:49 -0800
> "J. Liles" <malnourite@email-addr-hidden <mailto:malnourite@email-addr-hidden>> 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.

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Feb 24 08:15:02 2013