2 Sep
2014
2 Sep
'14
11:32 p.m.
On Tue, Sep 2, 2014 at 1:00 PM, Philipp Überbacher <murks(a)tuxfamily.org>
wrote:
For my taste this solution is far too hackish. I would not expect or
want any program to modify my ~/.jackdrc.
If jack is already running when the programs start then the ~/.jackdrc
is irrelevant. I'm still in favor of a simple jackstart program
(generic if possible or especially for jack).
The only issue I see with such a program is that it may be hard to tell
when jack is actually started. Maybe I'm wrong and there is an easy way
to tell that I'm not aware of. Maybe something in the jackd API would
help? Would jackctl_server_start() work?
http://jackaudio.org/api/group__ControlAPI.html#ga0ee7d8a3386503ce677f1adbd…
Regards,
Philipp
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
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 Just create a ~/.jackdrc and you're done.
That doesn't work per session, and mixing / live-performance have a
need for very different JACK settings, perhaps even different
interfaces.
It could be discussed to "highjack" ~/.jackdrc by copying an NSM
sessions .jackdrc to ~/ although a hack solution for a power-user,
I think its not a good way to go for beginners. We need something to
fix this... ideas?