On Sun, February 24, 2013 6:05 am, David Robillard wrote: > On Sat, 2013-02-23 at 17:01 +0100, Johannes Kroll wrote: >> A couple of days ago, I tried out non-session-manager, and thought, >> this is really nice. It really works in a practical, easy way. >> Unfortunately the number of apps supporting non-session is quite small >> (as is the case for *all* session management systems, AFAIK). There may >> be "a complete audio studio" supporting non-session, from one choice of >> sequencer to one synth to one sampler, but people like to use their >> favorite software. You can't just say, "if you want to use a sequencer, >> use X because it supports non-session". So its usefulness is limited. >> >> However, many apps support one session management framework or the >> other. So the obvious thing to do if you want to give people more >> choices would be to create some kind of interoperability layer between >> session management systems. >> >> What do you think about this? Is there an effort for something like >> this already underway? I personally think a good first step might be to >> create some compatibility between non-session (because I like it) and >> jack-session (because most people are using jack). > > I was tinkering with saving sessions in a format that is just a > directory with a shell script with a standard name (and perhaps some > standard arguments) which you call to restore or do other things. > > Not sure if that's a really feasible solution in general, but it's > basically the only way to save sessions in a way that don't require a > specific session manager to load, and doesn't impose any file formats. > > Actually being able to restore sessions decently from a script requires > a few more sophisticated jack command line utilities (like a > jack_connect that can wait for clients and so on), but those are useful > anyway. > > I like the lowest common denominator, and UNIXeyness, and zero > imposition of syntax and so on, of this idea, but haven't really > investigated it or done much of an implementation. > > Being based purely on classic UNIXisms (directory and a script that > calls some utilities is all that's going on) is probably the only way to > actually get everybody to agree on such a thing. Standardization of > such a spec would only involved command line utilities/arguments, paths, > and environment variables. Thanks to the shebang mechanism, it would be > language agnostic as well. > > Personally I have no plans to prioritize this, but I think it's an > interesting area to explore. >
Why do applications need to support a specific session manager? The session manager just calls the JACK API to notify a client app that an update is required to the internal state. What else is there to bother with on the application side? -- Patrick Shirkey Boost Hardware Ltd _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
