Forum

Shift-selecting multiple nodes and IOBoxes? (Bonus: "hidden" ALT-click and ALT-drag functionality)

vvvv beta question
#1

Does anyone know of a way to select multiple nodes and IOBoxes? I know of dragging a selection, but I want to select multiple nodes and IOBoxes in a patch to copy. Shift-clicking on Nodes will add them to the selection, but Shift-clicking on an IOBox will cancel the whole selection. Also Shift-dragging multiple times doesn’t work, as it always cancels the previous selection.

Right now I can’t think of a way to achieve this, even though I don’t see a reason why it should behave the way it currently does.

Also just noticed 2 shortcuts that are not on the vvvv cheat sheet and I never noticed before, but are very handy:

  1. ALT-clicking on one or more selected node(s) or IOBox(es) duplicates it

  2. ALT-click-and-dragging a window moves it and can be “docked into” other windows, so they are tabbed. Doing the same and dragging away floats them again - this will make my life much easier dealing with tons of subpatches

I think they should be added to the cheat-sheet. Maybe it has in the mean-time, the one on my wall has been there for quite a while ;)

#2

the iobox-selection issue is something that has been bothering me for years. not a big deal but kind of unexpected (again and again).

#3

Also just noticed that SHIFT-dragging multiple selections doesn’t work as expected (ie. it doesnt work), when there is no reason why it shouldn’t.

The selection dragging also doesn’t scroll the spread (again, as one would expect), so dragging a selection doesn’t always work in very large patches.

I just wanted to align a bunch of nodes that are arranged next to each other (for more logical positioning and pretty patches), but even the 30" monitor is not large enough to show the full width of the patch.

Can we please have better SHIFT- and CTRL-selection or automatically scrolling patches when dragging selections :)

#4

ja, thats an old problem. i remember not getting that to work properly years ago. the only awkward workaround still is: instead of clicking the iobox in the center if you click it on its top or bottom 2 pixels it will keep the selection. see?

re alt+click to duplicate. possible that this slipped through customs. i was never really satisfied with this.

re docking see: the user interface in detail#docking

but you forgot to mention what you’d expect.

true but you can always use the wheel while dragging and ALT+wheel to scroll horizontally.

hope that helps.

#5

Oh, why? Sorry to ask, but imho it’s very quick and useful, and never happened something “strange” when using this combo.

#6

Thanks for your answer @joreg.

I will try that trick with the top and bottom, but yeah it just seems like it should work, but doesn’t.

The alt - click thing is nothing I really use and since there is CTRL-D, which has the benefit of aligning after the first duplication and then continuing that pattern. But I would keep it, its not getting in the way.

Ah I never noticed that part about docking - so many things still to learn :)

About SHIFT-dragging:

When I click and drag I can make a selection. Holding SHIFT and dragging another selction I expect all selected elements to be added to the selection. Those that were already selected remain selected. Holding CTRL will remove any from the selection, unselected ones stay unselected. Panning with right-click dragging should still work and keep the selection intact. That way I don’t need to use the mousewheel (but its a good workaround for now).

Also dragging a selection to the edges of the patch should start to auto-scroll in that direction unless it has hit the top or left edge of the patch. Thats basically how it works in most software where a selection process is required - most adobe stuff, etc.

Is it ok to mention that I would love to zoom in and out like in the Finder :P

My favourite shortcut so far: CTRL-ALT-clicking on a input pin for R node and S node for output pin. Could I suggest that middle clicking on a S R Node will set its descriptive name to the pin it is connected to, like for IOBoxes. I usually set the descriptive name for better seeing what an S or R node does and this would make that much quicker.

I know you are probably working on a lot of “big stuff”, but I hope those small User Experience improvements can make it into updates too.

Thanks!

#7

i have been secretly hoping for that S+R auto-naming feature as well.

to prevent confusion what the S+R nodes are sending and receiving, i made it a habit to assign descriptive names according to their send and receive variable name. so if you break something ending up with red R nodes you don’t have to figure out what it was supposed to receive.

so the procedure right now is:
create S node, type value name, copy+paste name to S node descriptive name,
make R node, paste name to descriptive name, wish for auto-naming

does this make sense:
if the S node input pin is connected to anything, use that name as descriptive name when middle-clicking

otherwise use the Send String name.

for R nodes i would prefer to always use the corresponding Receive String for easiest recovery from red nodes when auto-naming.

…so i just realized that we probably should make a new thread for this.

#8

yup +1

Thats EXACTLY how I always imagined it should work. Lets make a feature request thread for that!

I use S+R nodes all the time. Using the Finder, which I only really started recently has improved it a lot. Searching with “< s” and hovering over S or R nodes shows a link to their corresponding node - very helpful.

© vvvv group