fons@xxxxxxxxxxxxxxx wrote: > On Sun, Nov 01, 2009 at 10:38:26AM +1100, Patrick Shirkey wrote: > >> I guess it's because currently the change state is held in memory >> whereas allowing multiple instances will not provide a way to update >> the change state without a significant modification to the existing >> code? > > That does not affect multiple instances running on > different hosts (but displaying on a single one). > > It has always been possible to run more than one jackd > on the same machine (using different soundcards). > If after > 5 years of existence qjackctl still can't > handle that that situation, what's can be expected for > the future ? (It's probably the result of using the > toolset's (Qt) default configuration system, which > also results in the config file ending up in the > wrong place). > there's nothing to do with qt or whatever. while on the setup dialog, save/ok buttons are only enabled when at least one of the settings have changed. like most global application options, and the already infamous single application restriction option in particular, it only takes effect _after_ you quit and start qjackctl later. again, that's nothing to do with the wrong place of the qjackctl configuration file but _when_ the changes are committed to it: at program exit. btw, the configuration file is in ~/.config/rncbc.org/QjackCtl.conf. you're not supposed to mess around with it, unless you know what you're doing. whatever you do, do it when no qjackctl instance is running, otherwise it will get automagically rewritten when it quits. and if you have several instances of qjackctl going on, then you must know that the changes you do on the _last_ one that terminates are the ones that will prevail to the next. anyway, you better leave the file alone, only qjackctl itself is supposed to read or write to it, so what's wrong with the place? getting back to the ot: you could always run qjackctl against several servers and hosts, but you always needed to tell which server via JACK_DEFAULT_SERVER environment variable. now, with this latest change (qjackctl 0.3.5.7, svn head) you can name the server via the command line directly. the server name, when given implicitly by JACK_DEFAULT_SERVER _or_ explicitly via the newer qjackctl -n/--server-name command line option, adds to the unique instance identifier iif the single instance restriction is in effect. when in effect, you can only have one qjackctl instance running against each server name. what doesn't make sense, to me at least, is having two (or more) qjackctl instances running against the _same_ jack server. if you do that, it will be just a waste of resources and prone to confusion and race conditions that you should avoid at all times. again, the single instance restriction is just to enforce that wasteful and redundant scenario won't happen easily. now, issue as come of age when Jörn (and others before him, the trouble is not new, has been mentioned before on the lists) wanted to run one qjackctl instance locally and another from a remote host via X tunneling (ssh -X). as both qjackctl instances will run against the same X display/server and the default jack server name is implicitly the same (literally "default"), qjackctl will pick up the same unique indentifier and guess that an "equivalent" instance is already up and running. and will pass over window control to it, bailing out the newer on the block. truth is, qjackctl is showing its age and legacy status. its design has some lurking short comings and flaws that gets exposed when is tried against new ways and use cases for which it wasn't designed or required for. the latest changes are just patches, in the medical sense, workarounds to cope with this new use cases. hth cheers -- rncbc aka Rui Nuno Capela rncbc@xxxxxxxxx _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
