3 Sep
2014
3 Sep
'14
12:57 a.m.
On Tue, 2 Sep 2014 23:22:56 +0100
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
On Tue, Sep 2, 2014 at 11:06 PM, J. Liles
<malnourite(a)gmail.com>
wrote:
Well, I still think it is a good idea. It would not create problems for
you, simply because you're not forced to use this if it is realised as
a client in the spirit of jackconnect.
I did not know that nsm supports live switching of sessions without
restarting clients, but in case you need to change the jack sample rate
you most likely can't do that anyway. I guess that with that
functionality in use 'live switching' would not be possible or
only in special cases (identical jack settings).
That would be the only drawback I can see.
Regards,
Philipp
In my workflow, this presents no problem. If I
implemented this JACK
configuration feature, then I would have CREATED a problem where
there were none before.
Hopefully you can see why I'm not interested
in implementing this
feature.
Yep. Good point, it seemed like something that would be nice to
handle in NSM, but i now agree that NSM should *not* handle jack
settings. The user has to do this manually: its not feasible to
script / auto-save JACK settings reliably.
So before starting the NSM UI / nsmd, it might be worth checking if
JACK is running, and if its not, providing an option to ask
A) Do you want to start JACK a la ~/.jackdrc
B) Continue without JACK
C) Quit
Does that seem reasonable? I'm thinking about beginner users, who are
not familiar with the eco-system, and making this as usable as
possible.
Cheers, -Harry