1 Feb
2016
1 Feb
'16
5:40 a.m.
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?
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.
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net