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!
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!
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.
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.
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.
