1 Feb
2016
1 Feb
'16
5:54 a.m.
On Mon, Feb 1, 2016 at 1:39 PM, Jörn Nettingsmeier <
nettings(a)stackingdwarves.net> wrote:
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.
On 02/01/2016 01:28 PM, Kjetil Matheussen wrote:
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
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?
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