2 Sep
2014
2 Sep
'14
11:50 p.m.
On Tue, 2 Sep 2014 14:31:59 -0700
"J. Liles" <malnourite(a)gmail.com> wrote:
On Tue, Sep 2, 2014 at 1:00 PM, Philipp Überbacher
<murks(a)tuxfamily.org> wrote:
I have the feeling that we are talking past each other for some reason.
You kill and start all programs anyway if you switch sessions, why not
jack as well? It would only be natural. To be honest, I did not
consider the killing jack part so far.
How would you go about things as it is now if you want to switch
between sessions that require different sample rates?
You would close session one, kill jack, restart jack with the settings
required for session two and start session two. Why not include that in
the session management? It seems like the logical thing to do.
I do not want to rely on autostart, I want to explicitly start jack
with specific per-session settings as part of the session management.
I hope that makes things a bit clearer.
Regards,
Philipp
On Tue, 2 Sep 2014 19:42:16 +0100
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
I agree here too. All I imagine is something that is able to start
jack before everything else, nothing more than that. On the UI side
it could be a simple field where you enter the jackd command you
want to use for this session.
The whole idea of killing and restarting JACK is totally incompatible
with session 'switch' functionality. All clients would have to be
killed, JACK killed, JACK restarted, and clients restarted. Probably
even if the configuration isn't different, as it would be a PITA to
try to model JACK's state in that way.
To me, this looks like creating problems and complexity for no real
benefit. If autostart doesn't work, then that's a JACK problem and
should be fixed there. Or--just don't rely on autostart in the first
place. IMHO that's more of a workaround to allow 'desktop' type use
of JACK apps (probably with auto-connect as well) and doesn't apply
to a production workflow. On Mon, Sep 1, 2014 at 6:44 PM, J. Liles
<malnourite(a)gmail.com>
wrote:
Agreed, I think it's doable. It is little work per-program. I think
it would be sensible to check how real the performance issue is,
but the mtime check Len suggested plus some caching would take care
of it most of the time if the performance issue is real at all.
This is something that would go into the .desktop
files of
applications as a capability
Cool: then its time to make it work in the UI, and after that
bug-report every app that is useful with NSM and doesn't have it
in its .desktop. Certainly
I have no intention of adding any qjackctl like
configuration features.
Which also isn't what I'm suggesting