On 11/01/2009 01:37 PM, drew Roberts wrote: > On Saturday 31 October 2009 19:38:26 Patrick Shirkey wrote: > >> On 11/01/2009 10:16 AM, fons@xxxxxxxxxxxxxxx wrote: >> >>> On Sat, Oct 31, 2009 at 11:04:12PM +0000, Rui Nuno Capela wrote: >>> >>>> my bad. that particular qjackctl -X command line option was in fact >>>> suggested by me but, well, just didn't make through implementation ;). >>>> >>> The option in the setup dialog creates a chicken/egg situation. >>> If the 'single instance' restriction is active you don't even >>> get a chance to change it. Unless you are so extremely clever >>> to realise that in order to enable a qjackctl instance on a >>> remote machine you first have to modify the configuration of >>> the local one. It makes sense, yes, lots of. >>> >>> Just like some other things in qjackctl's setup. >>> If I want to change where qjackctl's main window will >>> appear on the desktop, I have to >>> >>> - Move it to the required place. >>> - Open the setup dialog. >>> - Make some unwanted change. >>> - Undo that unwanted change. >>> - Click 'Save', which without the two previous actions >>> remains disabled. Why is it disabled ? >>> >>> And still I've not seen any rationale for ever enforcing >>> a single qjackctl on any X server. >>> >> 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? >> > Well, when I run one on my local machine, I want any changed configs to be > stored for the local setup. When I run one remotely through an ssh tunnel > say, I want any changed configs to be stored for the remote setup. (I think. > Does that make sense?) > > I don't see much point of storing a local copy of a ssh tunneled config file. If you are tunnelling the config file should be accessed from the remote machine. It's different if you are using multiple qjackctls on the same desktop and connecting to local jackd instance/s as well as netjack'd instances on remote machines. That seems like a heavy deal and as Nedko has mentioned previously it can actually be managed by the LADI tools now although that requires running dbus too which is not to everyones liking. IIUC, the main problem right now is that only one instance of qjackctl can be run on a desktop. It also cannot connect to two different instances of jack dynamically. It appears to be a limitation of qt but if not it still requires some fairly tricky code to be integrated to the backend of qjackctl and ability to handle multiple config files, lash/ladi sessions, etc... There are a couple of ways to handle this with either multiple instances connecting to explicit running servers or one instance with multiple tabbed windows for each running server instance. Of course, Rui is more than capable of implementing both options but afaik until now neither have been explicitly flagged for development priority. Also there was a slight expectation that LADI tools would make qjackctl redundant or even unnecessary but that has not been that case in the slightest. Cheers. Patrick Shirkey Boost Hardware Ltd _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
