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

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.
discoverability, discoverability, discoverability.

Yes, exactly, and that's one of the points I was trying to make. Starting a jackd process

in the background without the user knowing is not good. Instead - and this is my highly

opinioned opinion - the client should sometimes also be the server, and all the server

options and feedback, should be accessible to the client.

Nothing of importance to the user should be printed to

stdout or stderr, or provided via a string as command line arguments. All communication

should be formally specified, both options for starting the server, and feedback from the

server. The driver programmer should assume that information printed to stdout or

stderr will never be read or understood. And in order for the clients to show/configure

the server part of the client, libjack should provide common GUIs that all

clients may use. This way, you may use Ardour, for instance, alone, but you

may also start the jack server with qjackctl or jackd first if you want to. Ardour will

tell you if it is functioning as the server, or not.