On Mon, Mar 23, 2009 at 11:50:55AM +0100, Atte André Jensen wrote:
I often heard that it's considered bad when
clients automatically auto
connect it's outputs to jack. I agree, mostly since:
1) This makes routing through other software before output difficult
2) The patchbay in qjackctl makes it easy to make auto connects anyways
But could anyone point me to some explanation from the devs (Paul Davis
for instance) of why this is considered bad?
You just gave two good reasons yourself...
I'm not a jack dev, but probably one of those who
have been very critical of auto-connection in the
past.
In the most general sense, jack clients should not
autoconnect (except when loading a saved session
in which they were connected), because the whole
point of using jack is that clients shouldn't care
how they are connected.
More specific, clients can't assume that any ports
are the ones that make sense to connect to, this
includes the first two physical outputs. Sending
a signal were it isn't expected may have all sorts
of unwanted, embarrasing and even potentially
dangerous consequences.
I've compared in the past a synth that connects to
the first two outputs to a keyboard player who
enters a studio and connects his instruments to
the studio monitor amps. Another scenario is the
same keyboard player installing his instrument on
stage and connecting it to the first two XLR
connectors he happens to see there. Which could
well be the inputs of the amps driving the HF
speakers.
IMHO no program should ever by default autoconnect.
In cases where it would be desirable for some or
many users to have it autoconnect, this can always
be specified in a global configuration file (i.e.
something like /etc/appname.config) that can be
installed without user action even by a binary
package manager. At least in that way it can be
disabled or overruled by a user who wants that.
Any configuration data used to control things
such as autoconnection (again, outside the
context of an app restoring a previous session),
should be specified in a way that does not depend
on any specific desktop support (i.e. not by a
Gnome or KDE configuration daemon, the users may
be running another desktop), and that also
is not specific for the tool used to build the
app (i.e. not in ~/.qt/whatever, the user should
not be required to know anything about application
frameworks).
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.