Moving all the cables on one port?

I haven’t found it in docs or my own usage, but is there any way to do this?

I’m envisioning something like a Ctrl-Shift-Alt-drag operation that picks up every cable on the clicked port and moves them all to whichever port we drop on.

I have run into a few cases (especially with the new stackable inputs) where it’s just tedious to have to drag and drop cables one by one. In a stackable hardware cable context, this is trivial and often what you want – just grab the bottom-most plug and carry the whole stack to the new jack.

More than happy to submit this as feature request, but wanted to ask first – it wouldn’t be the first time I asked about something like this and simply got shown how! :sweat_smile:

3 Likes

I’m pretty sure that feature does not exist, and it sounds like an interesting idea that could be useful in some contexts. I think this would be a good feature request - go for it!

1 Like

The port context menu allows you to click and drag on any one of the cables, letting you select any one and drag.

A more general implementation of your idea would be to extend the context menu option to Ctrl-Click and drag to move a stack starting from the selected cable and all above. So it need not be all.

1 Like

Instead of moving all your cables, you can build the ability to change the destination of your signal. In this example I used a mult module like the one from Autodafe but there are many others. Most are 1>4 or 1>8 but there is a 1>16 from DocB. If you need 8>1 you can use a mixer.

Then you build a switch using Patchmaster and Routemaster so you can switch your output to different destinations.

1 Like

Ooh, yes, I love that about the port context menu – and need to get that workflow into my muscle memory, even with the current features – and I like this idea even more. That might obviate the need for another key-chord (like the Ctrl-Shift-Alt I mentioned), too.

Something like this is a solution I’ve used, and it definitely works. With stacked cables, I don’t even really need the multiple outputs like you describe, just some “no-op” intermediate module to facilitate what I’ve described.

But I don’t much like it for some of my workflows, especially in the main (very large) patch I use for performance/recording. Mainly that’s for visual clutter reasons, but it also introduces extra (probably inconsequential) sample delays, and doesn’t lend itself to impromptu live patching, since I don’t typically know in advance that whatever experiment I’m working on is going to lead to a need for the feature.

2 Likes

That is exactly one of the primary uses of my THRU module.

2 Likes
5 Likes