yes, that's all true, but the JACK eco-system relies on a primary device as default, being the one that native JACK applications connect to automatically, if not told explicitly otherwise.
sure qpwgraph and qjackctl patchbays maybe used to workaround and re-connect any application, but the problem is the fact that some JACK clients auto-connect themselves on startup to the default ("system") device, usually the first internal or integrated mic (for input) and speakers (for output).
also, qjackctl when under PW premises, just functions as a pure jack-client ("Active" is displayed in main window); you may use most of its functionality but the Setup / Settings, which are only applicable to configure the genuine jackd(bus) service; when in this mode the sole parameter you may change in settings is the buffer-size (in frames/buffer).
hth.
yes, that's all true, but the JACK eco-system relies on a primary device as default, being the one that native JACK applications connect to automatically, if not told explicitly otherwise.
sure qpwgraph and qjackctl patchbays maybe used to workaround and re-connect any application, but the problem is the fact that some JACK clients auto-connect themselves on startup to the default ("system") device, usually the first internal or integrated mic (for input) and speakers (for output).
also, qjackctl when under PW premises, just functions as a pure jack-client ("Active" is displayed in main window); you may use most of its functionality but the Setup / Settings, which are only applicable to configure the genuine jackd(bus) service; when in this mode the sole parameter you may change in settings is the buffer-size (in frames/buffer).
hth.