[LAU] qjackctl patchbay

Rui Nuno Capela rncbc at rncbc.org
Fri Apr 18 04:51:51 EDT 2008

On Fri, April 18, 2008 00:27, Fons Adriaensen wrote:
> On Thu, Apr 17, 2008 at 11:59:50PM +0100, Rui Nuno Capela wrote:
>> problem 1 is an old one and is due on lack of a better mapping
>> algorithm between actual jack graph and qjackctl patchbay models:
>> - jack graph is represented by connecting nodes which are the actual
>> individual  ports;
>> - qjackctl patchbay is represented by nodes (sockets), which aggregates
>> an ordered set of ports (plugs), intentionally connectible in turn, when
>>  actively available.
> The 'ordered set' seems to follow different rules than the
> ordering of ports in the main display. A similar thing happens if you
> select two apps expecting that connections will be made in the order they
> are displayed - usually it's different.
> Whatever the model, I assume it can represent an arbitrary set of
> connections. If not it's a wrong model. If it can, why doesn't that happen
> when you make a snapshot ? What is the purpose of making *other*
> connections ?

i'm sure the biggest problem here is the braindead snapshot feature which
doesn't do what you really want ootb. and the keyword here is the ootb;)

suppose you have this connection scenario:

  client_a:out_1 -> client_b:in_3
  client_a:out_2 -> client_b:in_4
  client_a:out_3 -> client_b:in_2
  client_a:out_4 -> client_b:in_1

then the snapshot will make it like:

  socket_a   -> socket_b
    client_a      client_b
      out_1       in_1
      out_2       in_2
      out_3       in_3
      out_4       in_4

if you activate this it won't do what you want, sure. that's why you'll
have to tweak the patchbay layout a little. read on

the correct patchbay would be exactly this one:

  socket_a1  -> socket_b2
    client_a      client_b
      out_1       in_3
      out_2       in_4

  socket_a2  -> socket_b2
    client_a      client_b
      out_3       in_2
      out_4       in_1

you see? at least you should have to copy either said sockets, remove half
of the ports(plugs) on each one and reorder the plugs in one other case.

imho, the big question is not whether the patchbay model doesn't fit to
all purposes, but whether the current super-naive snapshot mapping is any
better than not having one :)

>> the other two problems (2+3) are somewhat moot imho. yes, you'll always
>>  have to save the patchbay profile, so what?
> A collection of useless files that have to be deleted.
> I like to keep my home dir clean (the junk yards are at
> deeper levels). If you could at least save to an existing file the pile
> wouldn't grow so fast. Imagine that emacs wouldn't allow you overwrite a
> file...

aha. so you can't save to an existing file? now that's a bug that i wasn't
aware of. afaict that doesn't happen here, as it always asks whether you
want to replace the old file or not.

i guess a split into the old-school "Save" and "Save As..." options is in

> As far as I can see there is no technical reason why a
> patchbay should saved before it can be active. Nor is there any good
> reason to impose this rule.

yes, you're right, there is no reason at all but an old implementation
one. a very old in fact (4 years?:)

>> all suggestions are welcome,
> I have three:
> 1. Snapshot = exact copy of existing connections.

yeah right :o)

> 2. 'Current' patchbay exists without being saved.

to be 'Active' a patchbay must be materialized in a file first. i still
believe this is a minor hindrance but i get the point.

> 3. Allow overwriting files.

are you sure that's not possible already?

> I imagine that 2+3 would actually simplify the code.

eheh, i'm always found to quote this "don't fix what isn't broken" :))
snapshots aside, maybe the biggest miss on this current patchbay
implementation is that it hasn't support for jack-midi, yet ;)

thanks for the heads-up suggestions, nevertheless

rncbc aka Rui Nuno Capela
rncbc at rncbc.org

More information about the Linux-audio-user mailing list