23 Mar
2009
23 Mar
'09
7:14 p.m.
nescivi:
On Monday 23 March 2009 14:58:38 Kjetil S. Matheussen
wrote:
Letting jack autoconnect doesn't prevent applications from
setting up a custom connection system, so the above
suggestion is beside my point, and it doesn't address the
problems I was addressing either.
The problem with jack is that application
writers simply don't bother to do all the work required
to handle configurable connection handling,
and instead they just autoconnect to the physical outputs.
If jack had autoconnected by default, we wouldn't have
had this problem.
Without that, the other things I said would have
been incredibly stupid.
I don't think JACK should be complicated by defining autoconnect
mechanisms in
there.
Applications should provide the option and configuration for it.
I think the proposals given for the app to ask upon first startup (either
via
a GUI if the app has a graphical interface, or through command line
interface
if not) to the user how you want to configure the behaviour is the
clearest
way.
The configuration dialog can suggest the first hardware ports by default,
if
that is the expected most common user case.
That way the user is aware that he can configure it, and can adapt the
program
to her needs. i do agree that it would be good to define some
"system aliases" so that
it was possible to reliably and controllably discover *which* physical
ports to connect to if autoconnect is going to be used.
That sounds too complicated. Why not just add a command line option for
jackd for selecting which client to autoconnect to?