[PlanetCCRMA] status for updated jack-audio-connection-kit

[Rui Nuno Capela]

Ron,

>> > <snip> There's been updates to Qjackctl too. I was
>> > gonna send in a bug/usability report on its
>> patchbay but didn't want to until I run the most
>> recent release.
>>
>> Take your chance and send those reports in :)
>
> The Connections interface is intuitive. Routes are
> established by drag-n-drop. The Patchbay leaves this
> paradigm and forces the user to learn another
> interface.
>

That's true.

> The patchbay would be easier to use if we could create
> "sockets" with multiple plugs where routes can be
> established by drag-n-drop of the plugs. We currently
> create a socket and plug for every route:
> Rosegarden_output-L(Socket): master out L(Plug)
> Rosegarden_output-R: master out R
>
> This could be:
> Rosegarden_outputs: master out L/R
>
> Add drag-n-drop to the plugs and the interface is
> cleaner and more intuitive. I had to scratch my head
> half bald before I could making sense of the current
> design.
>

Let me tell you that the initial paradigm that I had in mind was about
modelling a real cable-patchbay rack, with normalled, half-normalled and
full-normalled socket configurations, etc. as cables plugged between input
and output sockets (in the 'real patchbay' these would be 1/4" jack
plugs/cables, or XLR, whatever). Suddenly this model was left in the
limbo, but the framework is all there.

I believe that one serious problem is just the complete lack of
documentation about this QjackCtl patchbay thing, other than some rare
notes found while browsing deep some hidden maillist archives ;)

OK. The main idea of the QjackCtl patchbay is all about making logical
groups of JACK client ports into one said "socket" and actively
maintaining logical connections whenever both ends show up in the JACK
graph.

A patchbay "socket" maps to one JACK client instance and is composed by
one or more "plugs" which maps one-to-one to corresponding JACK ports. As
I believe is the most common usage, you can specify a stereo channel as a
socket (client) with two plugs (ports).

On this patchbay model, you make connections between sockets. When two
sockets are said connected, it is implied that each one of its plugs is
about to be connected in turn, one by one, in a one-to-one basis.

Take special note on the plug/port order in the socket plug list, as each
plug of each other socket is about to be connected in the order they're
listed on either end. For example, in the stereo case, you have to agree
to yourself to list plugs _always_ in the very same order, either (L,R)
_or_ (R,L), unless it is your intention to connect otherwise.

In the your example, you should have as an Output Socket:

  Name:   "Rosegarden Master Out"
  Client: "rosegarden"
  Plugs:
       1. "master out L"
       2. "master out R"

and, as an example Input Socket:

  Name:   "Ardour Master In"
  Client: "ardour"
  Plugs:
       1. "Master/in 1"
       2. "Master/in 2"

then, if you connect these two sockets;

  "Rosegarden Master Out" -> "Ardour Master In"

you should see, provided the patchbay is activated, that you will always
get the following JACK ports connected, persistently:

  "rosegarden:master out L" -> "ardour:Master/in 1"
  "rosegarden:master out R" -> "ardour:Master/in 2"

whenever rosegarden and ardour are live and kicking.

One other thing that might be somewhat misleading, is that snapshot
feature asked on a new patchbay definition (i.e. you click on the "New"
button).

This snapshot feature takes the current JACK graph state and tries to
mimic a corresponding patchbay layout. Truth must be told: this snapshot
feature is just a starter. It is _not_ a straight conversion from the
actual JACK graph and the patchbay model. Take it more like a template,
which your connections layout will be based.

Again, lack of documentation is the main culprit here ;)


> TOPIC CHANGE
> When I say the Connections interface is intuitive that
> shouldn't be confused with usable. The solution of
> wires becomes an indecipherable visual entanglement in
> every session I do as track and jack client counts
> increase.
>
> The best solution I'm aware of is what Jesse Chappel
> has implemented in the Ardour Track Bus Inspector. I
> don't know if it's the ultimate end of story but it
> remains usable where the wire paridigm falls.
>

Yep. Thankfully, ardour has its own connection/patchbay :)

This is surely a topic open for ideas. Have you looked into the
"competition" lately? I wonder how all that spaghetti can be handled
visually by Dave Robillard's patchage.


Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org