<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 1:39 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="">On 02/01/2016 01:28 PM, Kjetil Matheussen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Instead - and<br>
this is my highly<br>
opinioned opinion - the client should sometimes also be the server,<br>
</blockquote>
<br></span>
i disagree, most emphatically. the client should never be the server. do you want to spend ages figuring out whether a jack problem happened with an in-process server or external server, each time a user cries their eyes out on IRC? do you want to battle all the conceptual misunderstandings about how in-process servers are faster, and out-of-process servers are more robust, and sound warmer? why? what's so bad about a clean conceptual separation?<span class=""><br>
<br></span></blockquote><div><br></div><div>Two reasons:</div><div>1. No need to use anything other than Jack. Ardour now has got the option of not using Jack. Shouldn't</div><div>have been necessary.</div><div>2. It feels like a server configuration protocol will stabilize faster if clients also can function as servers<br></div><div>since more code is using it, not just qjackctl.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and<br>
all the server<br>
options and feedback, should be accessible to the client.<br>
</blockquote>
<br></span>
now that is something we can agree on, but that's *completely* orthogonal.<br>
<br>
but the way i do it, i open qjackctl and look at the message window. problem solved. and i guess i can explain that to users far more quickly than you can implement a new message passing API for jackd.<br>
developer time saved, user understanding improved. two sacred pillars of the open source culture.<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div>It works, but the more components you glue together, the higher the chance is for something</div><div>to fail. For instance didn't the messages window in the windows version of qjackctl show anything</div><div>coming from jackd until autumn 2015.</div><div><br></div></div></div></div>