Why would you want to reduce the amount of snaps? Can you show me an example in a GIF that shows the unwanted behavior?
Currently, SHIFT-click creates a pad. But yeah SHIFT would be a nice key for that functionality.
But only if a link is currently drawn and left mouse button is clicked, no?
Currently pressing shift while dragging things locks the translation to the x-axis.
Didn’t know that.
It’s not really reliable though.
I have a strange question, perhaps.
Has no one ever considered snapping to a grid? A grid in the workspace?
yes, that’s how i imagined it: while dragging nodes or other elements, the shift-axis-constraint can now be changed to (de)activate snapping.
when a user can change in the settings if snapping gets activated or deactivated, it should fulfill the different habits.
I thought about it! I don’t think adding grid is a good idea as it’ll always feel rigid. You can play with an example here. Also a node can stretch and squeeze freely and it’ll inhibit that movement
2 Likes
Yup, here. You can see that my Rectangle node has too much jagged movement as the snapping logic is trying to align with each input pin of Group node.
It doesn’t make much sense here when Rectangle node tries to snap to align with Group’s 3rd and 4th input pins (which are Debug and Enabled respectively).
Again, I can only see a user to align nodes in one of the three options I mentioned in my previous comment:
Another example: This Circle node has many input pins, the second being Radius. Now if I have dragged out an IO box from the Radius pin, I don’t have a need for IO Box to align with other pins:
2 Likes
@ajitid I think there are three rules of magnetisation here:
- To the left edge of the neighbouring node.
- To the pin the link is connected to.
- To the right edge of the neighbouring (connected?) node
But honestly, why would I want to magnetise to the right edge when I’m dragging?
This rule should only be active when resizing. Ideally.
An operation node of record/class would output data from its second output pin.
For example, one may want to right align * node with AnOperation node here:
Here’s a case where I see too many jumps because it is also trying to align to nodes which are not in its immediate vicinity. I don’t know if others like this behaviour, but this can also add up friction.
When I’m thinking about snapping, I only think about snapping to the node just below or just above it, and I do not care about snapping to the faraway nodes.
(Others please chip in, and also please don’t hesitate to tell me if I’m just adding to the noise.)
Totally agree with you @ajitid. Just cross-referencing a post I opened earlier that goes in the same direction.
I also thinks it tries to snap to too many things by default, and would agree the behavior you’re describing here is the right way to go :
And also, I guess snapping to elements that are super far away should not make sense in most cases.
But of course there are still cases where you want to do those things, which is why I was suggesting there could be a modifier key that applies the current behavior, which is “try to snap to anything you possibly can”. The default behavior should be smarter in the sense that
- It only snaps to your surroundings
- Only to stuff you’re most likely interested in
What do you think about the magnet strength? I have the feeling in other software like Affinity Designer, it’s much more gentle, way less abrupt than here. Maybe that would make it feel smoother and less invasive?
That certainly will! Magnet strength is certainly high in vvvv and there’s also the fact that both Affinity Designer and Figma dynamically reduce the magnetic strength the more you zoom onto the canvas.
Here’s a demo, though I’d encourage you to fire up a design tool and try this by yourself:
a. When zoomed in, X snaps away from 816.3 to ~819.2
b. When zoomed out, X snaps away from 816.3 to ~825.3
The magnetic strength in vvvv is fixed, however.
Figma goes in a little further, and probably takes velocity into account.
I agree! I think “try to snap to farther elements” should get enabled if you have zoomed out on a patch.
I understood that you all suggest that the user has to hold shift in order to get no snapping. So when drawing a link I have to hold shift until the very moment where I finish the link in order to not get the new node placed on that non-snapped location.
But now the node browser doesn’t open as shift-left-click already means something else. Same applies for shift-alt.
We could switch to something like
- CTRL-click opens node browser and asks for what to create: Pin, IOBOX, Pad
- SHIFT and ALT can now be user for something else.
But I guess for such a change we need to have some longer internal discussions. There are for sure different ideas and opinions. It’s just not completely trivial.
We also could come up with different modifier keys like “s” for snapping. Or we could argue the user doesn’t have to hold SHIFT. It is a toggle.
What’s you favorite?
I am one of those that wants to have a modifier that enables snapping. No snapping being the default.
Feels like Alt
… which you would do by holding the modifier key?
This has been a long time coming.
We need to think hard about UX.
I talked about this in the other post:
And we all need to be aware that this all needs to be integrated into a larger task of improving the experience.
At the moment there is a ‘zoo’ of different approaches and technologies. For example, I have started to actively use ‘drag and drop links’ and ‘connectable nodes’, although I used to do things differently. At the same time, there are a lot of ‘old style’ and ‘new style’ ways of doing the same thing. Usually the ‘new style’ is better, but there’s a group of people who have a hard time accepting that, for example.
We need to sort out this ‘zoo’ and make a strong decision to restructure some of the approaches.
Right, I didn’t notice it at first, but the strength of the pull should depend on the zoom!
That’s where I started the conversation!
The rules need to be much smarter than that. It’s cool that we can spell them all out, but we also have to realise that it might take quite a bit of effort to create the ‘engine’ of these rules.
This ‘engine’ should take into account the environment and probably be able to do checks for reach to objects, intersections with other nodes, active connections, maybe some kind of fine-tuning based on object type.
Yes that was the initial idea. Could also be a toggle, press once to (de) activate.
Has no one ever considered snapping to a grid? A grid in the workspace?
You can in Max. I use it by default (because I think patching in Max is a mess and it kind of “helps” in a way, but still a mess).
I think grid snapping works if and only if every single object’s sizes are multiples of the grid pitch: node width, node height, pin spacing, etc.
Otherwise you end up having the left border of a node on the grid but the right border is not, then it introduces offsets that mess everything up…
I feel a grid is the poor man’s smart snapping 😅
Feels like Alt
In Rhino and Affinity you hold Alt to disable all smart snapping iirc.
@yar @chk
I’m with @chk, I would never patch without snapping again, for sure; even in its current state, which I’m pretty happy with tbh.