On Sun, 4 Jan 2015, gnome(a)hawaii.rr.com wrote: It is usable as is. No GUI? remember Jack itself has no GUI either, qjackctl does (maybe sortof) support it though. Both Jack and netjack are audio infrastructure and best started from commandline anyway. Jack must be restarted (audio stops, connections fail) to make changes. I have not found it problematic, but to be honest, I have not pushed it very hard as I had a less than stellar computer when I was playing with it. (I did run it with 20 channels or so, but with the slack latency option) jack_control can be used to change things sort of on the fly. What is missing, is a patch panel that can change patches on the other end. I think a MIDI over IP or OSC or http solution might be best... http and OSC could well be wrapped into one, I think. Again, such a GUI would not be a part of jack (in the same way qjackctl is not) but might well be thought of that way (like qjackctl is by many) if it wad well developed. Commandline over SSH works fine of course and it would be possible to run a second instance of qjackctl using ssh -Y. Also, Fons has a very robust AoIP setup that is worth trying as well. It is also command line, but can be changed on the fly without stopping jack on either end to change number of channels etc. A GUI developed to change jack connections remotely for the above case would probably work for this as well. Also, this AoIP solution does not care what version of jack you use as it is client based and not a back end or module. I have tried both netjack2 and zita-n2j (have I got it right?) and would go with the second for anything across rooms or anything that did not involve mics on both machines in the same room.... and maybe even then after testing, though I think if the mics are in the same room, the audio IFs should all be on one machine anyway(my preferance). For accessing a software synth there should be no problem. -- Len Ovens www.ovenwerks.net