<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 1:09 PM, Jörn Nettingsmeier <span dir="ltr"><<a href="mailto:nettings@stackingdwarves.net" target="_blank">nettings@stackingdwarves.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br></span>
i guess my point in a nutshell is this: if you invent some user-friendliness that shields the user from having to manually set up a key part of their workflow, you are responsible for making sure they are aware what's being done, and ideally learn how to do it/control it themselves.<br>
discoverability, discoverability, discoverability.<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Yes, exactly, and that's one of the points I was trying to make. Starting a jackd process</div><div>in the background without the user knowing is not good. Instead - and this is my highly</div><div>opinioned opinion - the client should sometimes also be the server, and all the server</div><div>options and feedback, should be accessible to the client.</div><div>Nothing of importance to the user should be printed to</div><div>stdout or stderr, or provided via a string as command line arguments. All communication</div><div>should be formally specified, both options for starting the server, and feedback from the</div><div>server. The driver programmer should assume that information printed to stdout or</div><div>stderr will never be read or understood. And in order for the clients to show/configure</div><div>the server part of the client, libjack should provide common GUIs that all</div><div>clients may use. This way, you may use Ardour, for instance, alone, but you</div><div>may also start the jack server with qjackctl or jackd first if you want to. Ardour will</div><div>tell you if it is functioning as the server, or not.</div><div><br></div><div><br></div></div></div></div>