On Sat, 23 Feb 2013 19:15:16 -0800 "J. Liles" <[email protected]> wrote:
> > 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. OK, that makes sense. Porting existing sessions would be a good first step, but still, it sounds cumbersome. I'm not sure if it would be much easier than starting the apps by hand. >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. In what way? I don't know much about LASH and LADISH, but I'm looking at the jack-session api docs [1] right now. From what I can see, it does everything it needs to do. There is also a GUI available in qjackctl which I use anyway. I think that I, as a user, would be happy with jack-session, if only my favourite apps would support it! >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! True, but patching to what? NSM? I like NSM but I'm not convinced that it is "the best" possible SM. Others may think similar. Some people may still want to support jack-session, simply because they think it is the way to go, even if you think it is inadequate or obsolete. You won't win everyone over to use NSM. Or *any* particular SM, for that matter. It's cat herding. For this reason, I still think an interoperability layer would be a good thing. If it is technically feasible I'm not sure. [1] http://jackaudio.org/files/docs/html/group__SessionClientFunctions.html _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
