On Wed, 3 Sep 2014 17:27:11 -0700 "J. Liles" <malnourite@xxxxxxxxx> wrote: > On Wed, Sep 3, 2014 at 2:08 PM, Philipp Überbacher > <murks@xxxxxxxxxxxxx> wrote: > > > On Wed, 3 Sep 2014 20:27:11 +0100 > > Harry van Haaren <harryhaaren@xxxxxxxxx> wrote: > > > > > On Wed, Sep 3, 2014 at 7:57 PM, J. Liles <malnourite@xxxxxxxxx> > > > wrote: > > > > workflow that is already supported just fine by dealing > > > > with it 'manually'. > > > Yes, manually setting JACK before starting a session is the only > > > and best solution that scales. As you mentioned, transporting a > > > session to another machine would mean JACK's settings get borked: > > > therefor this is *not* something NSM should worry about, or > > > implement. > > > > I completely disagree. Moving the session from one machine to > > another may be one use case, but a rather special one. At least > > it's not something I would do. > > On the other hand, remembering which jack settings are required for > > which session is something that NSM should remember for me. > > And given that I proposed the jackstart client as an optional > > client, something you can use or not use, same as jackconnect, your > > argument falls flat on its face since you could just not use the > > jackstart client and still handle jack manually. > > > > You would also not need to start all clients in a pre-defined order, > > you'd just need to make sure that jackstart starts before all > > others. > > > > The complexity isn't much less if it's only one client. And then NSM > needs to know to treat that client specially... That part was clear pretty much from the start, as you can see from the discussion between Harry and me. > > And be honest about one point: How many clients manage to 'live > > switch'? I guess that most don't. Even if they do, what's the cost? > > A few seconds at session switch time at most, which is completely > > negligible IMHO. I know that for you this is a feature that is > > important because other session management systems don't do it, but > > I seriously doubt that it matters for any other reason. > > > > You can lead a horse to water... Ad hominem. > People said the same thing about kernel suspend to RAM/disk. Yes, it > took a while to get everything working and there are still some > drivers that don't cooperate, but once you've seen the light you > won't want to go back to rebooting ever again. Seems like the dark > ages now. You can keep this red herring. I've made my suggestions with the goal to improve the user experience of nsm, take the or leave them. Regards, Philipp _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
