On Mon, Feb 1, 2016 at 1:39 PM, Jörn Nettingsmeier <nettings@stackingdwarves.net> wrote:

On 02/01/2016 01:28 PM, Kjetil Matheussen wrote:

Instead - and
this is my highly
opinioned opinion - the client should sometimes also be the server,

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?

Two reasons:

1. No need to use anything other than Jack. Ardour now has got the option of not using Jack. Shouldn't

have been necessary.

2. It feels like a server configuration protocol will stabilize faster if clients also can function as servers

since more code is using it, not just qjackctl.

and
all the server
options and feedback, should be accessible to the client.

now that is something we can agree on, but that's *completely* orthogonal.

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.
developer time saved, user understanding improved. two sacred pillars of the open source culture.

It works, but the more components you glue together, the higher the chance is for something

to fail. For instance didn't the messages window in the windows version of qjackctl show anything

coming from jackd until autumn 2015.