On Sat, 23 Feb 2013 19:15:16 -0800
"J. Liles" <malnourite(a)gmail.com> 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