On Sat, 23 Feb 2013 17:28:49 -0800 "J. Liles" <[email protected]> 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. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
