<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 31, 2016 at 4:50 PM, Kjetil Matheussen <span dir="ltr"><<a href="mailto:k.s.matheussen@gmail.com" target="_blank">k.s.matheussen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div></span><div>I meant server options. Driver name, realtime on/off, driver options, timeout, etc.</div></div></div></div></blockquote><div><br></div><div>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 ...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div></span><div>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.<br><br></div></div></div></div></blockquote><div><br></div></span><div>But it's better than having different GUIs in every client for configuring jack.</div></div></div></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>what problem are you actually concerned with fixing? what users does it affect? when?<br></div><div></div></div></div></div></blockquote><div><br></div></span><div>I think I have listed the problems. The far worst problem is that there</div><div>is no proper error response when a driver doesn't start. Especially on Windows,</div><div>where qjackctl is quite buggy and portaudio often refuses to start.</div></div></div></div></blockquote><div><br></div><div>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.  <br></div></div><br></div></div>