On Sun, Jan 31, 2016 at 4:50 PM, Kjetil Matheussen <k.s.matheussen@gmail.com> 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.

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.

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.

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.