Feature request, Add the ability to hide jack clients and their connections

[Houston4444]

Initial issue: Houston4444/Patchance#2

@ovenwerks said :

Pipewire adds extra jack clients that add many ports and connections that are not needed for normal use (sometimes jack gets cluttered too). It would be wonderful if the client dropdown had an option to "hide" that client and its connections for more clarity in the graph. There would need to be a sub menu in the main menu for unhiding either all clients or specific clients.

[Houston4444]

So, wrap boxes is not enough ?

I am dubious about the question, I think to the fact it can be dangerous for the user if (s)he forgets that some clients are hidden. On the other hand, that was my first impression trying pipewire : what a complex and cluttered patchbay ! I don't need to see all theses clients.

The idea is not bad, there are different ways to implement this.
Structurally, they can be just hidden widgets, but it will generate bugs to fix elsewhere (elastic scene, prevent overlap option...), the advantage is that they would be visible in the context menu directly. Disadvantage is that they will consume as much resources as if they were visible, and this canvas has not been designed to manage hidden widgets.
Another way to do that is to not add them to the graph, keeping them in the abstract overlay, work could be done to make them visible in port context menus, but that is a quite important work.

The first one way is probably faster to do, the second one is probably safer.

In all cases, I really don't know how to deal with them in the filter bar (search a box), ignore them ? add an alert label that says one or more clients match with the pattern but is invisible (and may add a button to the filter bar to make it appears) ?

In short, it's not as simple as it sounds.

[ovenwerks]

First off, houstonpatchbay is already much better than any of the other patch bays I can find. Wrap helps and seems to remember clients that go away and come back.

"In all cases, I really don't know how to deal with them in the filter bar (search a box), ignore them ?" In my mind yes. Ignore them. But I am rarely right :) That aside, there are bound to be some people who actually like the Gnome desktop (I find it unusable) and might see the search box as the easy way to unhide a box. I have dyslexia and remembering the name of a box or using search for anything is difficult, so I know I am blind to uses of the whole search thing. A global button (or show hidden might be more obvious) would suit both.

I am looking for other avenues as well, if PW can hide the monitor outputs (which should be useless in the Jack graph anyway as one can always grab the same signal as the inputs already), maybe pw can hide other clients/ports as well.

And yes: "In short, it's not as simple as it sounds."

[Houston4444]

houstonpatchbay is already much better than any of the other patch bays I can find.

Nice to hear, I agree ;)

there are bound to be some people who actually like the Gnome desktop (I find it unusable)

ah, I am not alone to find it unusable.

maybe pw can hide other clients/ports as well.

Solve the problem at source would be great. I don't say that I don't want to do this feature, but as I said it can be quite long, and there still are things to do with the patchbay (see https://github.com/Houston4444/HoustonPatchbay/blob/main/plans.md). It won't be a priority for me.

[ovenwerks]

On Thu, 1 Dec 2022, Houston4444 wrote: things to do with the patchbay (see https://github.com/Houston4444/HoustonPatchbay/blob/main/plans.md). It won't be a priority for me.

Looking at those, in particular "meters": It is the meters in pavucontrol that creates most of the mess in graph. However, if it is just the signals on that client I guess the connections would be hidden. But other applications like Ardour would show all of the patch bay's ports to put those meters in (in this case the connections would not make things any worse). I would say that meters at most should be temporary per client and never overall. Sort of, "hey I wonder what the levels are there" right click meters... then shut it off after. I am not sure if that makes more code or less ;) Meters do take up dsp time... ei. cause xruns The difference between "views" and "zones" is very subtle to me. I would welcome the idea that I could put certain clients in one part of the virtual screen (perhaps where I can't see it) and then not have to think about them. The only problem is that the screen would want to centrre oddly. So keeping the centre function to a zone and ignoring clients outside that zone would be just as good as hiding those clients I think. To me, views, zones and hide are meant to accompish the same thing. While I might prefer one over the other, that is minor, having any one of them would do what I want. Personally I only care about two zones, desktop and not but I can imagine a more complex setup where several clients might make up a synth for example and be best kept separate from the recording application. So more than two starts to make sense.

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you werementioned.[ADBJVSI363QYKQW7V5R2NB3WLBRY7A5CNFSM6AAAAAASQA72XGWGG33NNVSW45C7 OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSPPKGXA.gif] Message ID: ***@***.***>

[Houston4444]

About Meters:

I strictly have no idea for the moment how to implement this (how I should code this and how it could look). Of course, it won't be running by default for all connected ports, keep the patchbay a light thing is a priority. By the way, the part of the work done for optimize the code is nearly as big as features added since Carla's patchbay fork.

About Views and Zones:

These are really two different things.

Views are just different position configurations for boxes. If we don't have "Hide Jack clients" feature, you can't achieve what you want with Views. When you filter ports by type, you activate another view, if you show for example only MIDI, move some boxes and go back to AUDIO|MIDI|CV, then go back to MIDI, you will see that positions (and wrap and split states) are stored per view. The idea here is to can add views and switch from one to another if it is more readable for some usages. I don't think it would be used by a lot of people, however, it is nearly nothing to code, everything already exists in the background.

Zones are group of boxes, we could for example make a zone with Ctrl + clic and drag in the background, instead to just select boxes, it would create a zone with a semi-transparent background. Then user could move the zone directly as a box (it would be also an object for the "prevent overlap" algorithm). Zones should be wrappable too. There are some behaviors to define, such as, should a zone be displayed if there is only one of its boxes (I think no), should user name the zone, etc ...
It's a big job.

The only problem is that the screen would want to center oddly.

Elastic canvas is optional !