QjackCtl 0.2.22 released!

Aha, you caught me :o)

Badly as is the situation almost remains the same. "Howto" use the QjackCtl's most infamous feature, the Patchbay, has been a dark magic, only secretly whispered to the ears of LADs (cf. linux-audio-dev maillist archives).

As you migh know already I'm not too found of writing user documentation. Damn. This is old programmer dogma. What can I say? Sure, the same old story: no time. And you would ask: so what's the use?

You're right. And guess what? I need (your) help.

In the meanwhile, here follows some gossip about what's last posted to the LA* maillists:

--
The "Patchbay" window is a place where you declare your intention that some logical connections between some client/ports are to be scanned and maintained active and persistently. There you'll say that you want to keep a connection between two logical groups of ports. When, activated the patchbay code will scan and verify whether each one of the client/port ends are present and then connect those automagically if its the case.

The main purpose of the patchbay is therefore to maintain automatic connections, and _not_ disconnections.

However, there's one little feature that can issue auto-disconnections: that "exclusive" socket flag. When one socket is marked as "exclusive", it will be enforced that _only_ those connections that are declared for that socket will be legal and therefore actively maintained. All other sneaker/outsiders will be immediate and automatically disconnected. This is the only patchbay rule that shall feature implicit disconnections.

Everything else is all about making connections, _not_ disconnections.

If you want to disconnect something, you should do it explicitly in the "Connections" window. Always remember that the "Patchbay" window is not a view of the "Connections", rather just a model.

Hope I have helped somewhat. All this confusion is certainly my own fault, due to a viral lack of documentation ;) Anyway, now you should have a lil'better understanding of how misleading the "Connections" and "Patchbay" resemblance is.

Some (assorted) rules to have in mind:

1) You group all _or_ just a sub-set of ports into a so called patchbay socket. A socket is an ordered group of all or some client ports. You can have as many sockets as you want pointing to the _same_ client, but it is worthwhile to note that having duplicated sockets for the same client with the very same set of ports is just redundant.

2) You declare to connect sockets, not clients. When two sockets are said connected, that is regarded as a declarative rule to automatically connect those respective client-ports, one-by-one in that precise order. Again, the rule states for connecting ports, not just clients.

3) You're probably relying on the bare snapshot that is created while you set a new Patchbay definition. This snapshot is a rough and skewed image of your current client-port connections, that you _must_ regard just as a convenient starting point. Do not take it for granted OOTB. On most if not all situations you'll need to duplicate some sockets, trim each socket port list, reorder, and edit the connections between the intentional port groups (aka sockets).

4) You can edit and add sockets that refer to client/ports that aren't actually running, although it surely helps to get the client/port names right. Client names can be entered as regular expressions while you edit a socket definition. This is most convenient for matching those clients that have some pseudo-random number in their name suffixes (e.g xmms-jack pid).

5) The Patchbay rules are then only effective after you save and activate it.

Please note that the "snapshot" feature it's more like an helper than a solution. You'll most certainly have to edit the resulting patchbay layout anyway, to let it do exactly what you really want.

One thing that may lead to some confusion about this patchbay model is that you're grouping ports (plugs) under "sockets", not exactly JACK clients.

However, one socket maps onto one JACK client, but then you may have several sockets for the same one client. One can see a "socket" as just a way to group JACK client ports in a orderly fashion, nothing more, nothing less.

When you connect an output socket to a input socket, you're telling that you wish their respective ports to be (re)connected whenever actually available, and in a one-to-one order as of each socket.

It might be perfectly possible that the snapshot helper feature doesn't come out with what you really want exactly, specially on some rather complex audio connection topologies--and everybody can come out with one in no time, thanks to JACK again :) The snapshot is however a good start, better than from scratch, or so I thought.

OK. To make all this a little bit clearer, let's suppose you want to maintain the following connections:

   client_1:out_0 -> client_2:in_L
   client_1:out_1 -> client_2:in_R
   client_1:out_2 -> client_3:in_1
   client_1:out_3 -> client_3:in_2

To take advantage of the qjackctl patchbay feature, you must have the following patchbay definition:

Output Sockets

      Socket1
          Client: client_1
          Ports:
              out_0
              out_1

      Socket2
          Client: client_1
          Ports:
              out_2
              out_3

Input Sockets

      Socket3
          Client: client_2
          Ports:
              in_L
              in_R

      Socket4
          Client: client_3
          Ports:
              in_1
              in_2

And connect the above as:

  Socket1 -> Socket3
  Socket2 -> Socket4

Remember that, on this patchbay model, you're connecting sockets, not ports. When you connect two sockets together you're actually telling to connect each one of its ports, one by one in order. As you might see, this ordered set is crucial to which JACK ports will be actually connected.

Please check if you try to follow this model as close as you can, when preparing your patchbay. I hope you get it right by now, despite my dubious English ;)

If any doubt still remains, just send your patchbay definition file (.xml) and some clue of which connections you really want. Then I'll be pleased to send back a corrected one to you, if that should be still the case.

Cheers,
--
rncbc aka Rui Nuno Capela

The Novation Speedio is nominally non supported. However, iif it is USB Audio/MIDI class compliant it should work with the standard snd-usb-audio ALSA module. You probably can check that out, as the MIDI interfaces should show up and work alright.

However there probably should be issues with the audio interfaces, like crackling noisy and/or robotized sound ? If thats the case, you can try tweaking settings over the jackd parameters for the alsa driver: try with buffer sizes greater than 128 and with periods no less than 3. Sticking with the nominal 48000 sample rate may help. But these are just shots in the dark.

If that doesn't get things to sound right your audio device is definitively unsupported and will need the vendor (Novation) to agree and open up the technical/proprietary specs and let some smart ALSA developer be ready for the challenge :) Unless someone is brave enough and have plenty of time to do some reverse-engineering over the USB traffic on XP or OSX. Given the business (ie. lack of time) of all those great LADs I don't see that happening anytime soon. Without the manufacturer help most probably it won't happen ever.

Cheers,
rncbc aka Rui Nuno Capela