31 Jan
2016
31 Jan
'16
3:10 p.m.
On Sun, Jan 31, 2016 at 4:50 PM, Kjetil Matheussen <k.s.matheussen(a)gmail.com
I am fairly confident that what is better for most users is having a well
known point of control (e.g. cadence, qjackctl) to start and control JACK,
as well as the capability to start the server from scripts etc.
Qjackctl arranges to catch all output from the server, which is by far the
simplest way to present information to the user, especially in a context
where the reasons for failure can be incredibly complex. It might not work
as well on Windows as it does on *nix platforms, but I hardly think that
this would justify some new mechanism to pass failure information between
processes.
wrote:
I meant server options. Driver name, realtime on/off, driver options,
timeout, etc.
why does a client want these? it would not contain code to start JACK that
required any of this .... unless you're suggesting a different GUI to
configure the server in every client, which you're not ...
I don't anything perfect about jack_lsp
popping up a GUI dialog to
configure a server. I don't see anything good about a careful constructed
GUI application having to deal with the reality of a new dialog being
created. this isn't even close to perfect.
But it's better than having different GUIs in every client for configuring
jack.
what problem are you actually concerned with
fixing? what users does it
affect? when?
I think I have listed the problems. The far worst problem is that there
is no proper error response when a driver doesn't start. Especially on
Windows,
where qjackctl is quite buggy and portaudio often refuses to start.