Serious problems with automatic naming of inputs and outputs

I don’t understand why no one has brought this up before, but it feels like it’s been an ongoing problem for over a year now. Maybe it’s hard to explain?

Let me try. I often use Ctrl+LeftClick to create inputs. There is an engine that decides what to name the input, for some reason I used to find this much more convenient - the engine used to create names like “Input 1” and “Input 2”, but now I spend a lot of time renaming newly created inputs.

Also, I have recently discovered that inputs with an explicitly defined type copy the type into newly created inputs in this way!

There are many other places where this causes a lot of inconvenience. Can we have a closer look at this problem?

PinsAutoCreate_issue-NODE_2025.01.29-09.20.03
PinsAutoCreate_issue-NODE_2025.01.29-09.23.17

Imagine a huge patch where this is happening. Sometimes it takes a few minutes to realise what’s going on. I’ve had other cases where it’s been badly perceived and had a significant impact on the patching, but I can’t remember now.

The outputs have the same problem.

Oh yes, I gave examples of it happening in one visible area. Imagine if it happens in completely different places in the patch and you only see half of what’s going on.

1 Like

a) Removal of auto-renaming magic: Indeed, that was changed around a year ago. There are opposite cases where this was getting in your way, for example imagine you have a properly named pin like “My Context”, and you want to pass that one outwards at various places in your patch. The auto-renaming created “My Context 2” which was exactly the opposite of what you wanted. In general our thinking here was, no magic, just let the system tell us what is wrong. The example of yours is indeed unfortunate, because it doesn’t lead to a red link, but instead takes out the whole pin.
b) That the type annotation gets carried over to the renamed pin was I believe a feature request. Again you find other examples where not doing so was getting in your way.

If you have any good ideas on how to approach these issues please let us know.

Maybe other users are running into this too — I can’t be the only one having this issue.

It seems like the problem mostly comes down to frequency. Does the ‘context’ example happen often, or is it more of an edge case? The examples I’m dealing with pop up regularly. I never had issues with this behavior before, but now it happens constantly — anywhere from 3 to 10 times per session. I’ve even caught myself adjusting my behavior to avoid triggering it — I get a bit ‘twitchy’. Sometimes, the problem is really extreme, as you can see in the GIF. There have even been cases where the generic matched the input (or output), and I had no idea why the patch wouldn’t work. If there were issues with ‘magic’, I barely noticed them. Quite the opposite in fact! It was as if it was constantly warning me that I was doing something and that I should pay attention.

Ideally, there would be a second step when an option isn’t recognized — something like, ‘Do you mean input or input 2?’ Or even better, a menu showing existing pins, with ‘new’ at the top (because proper naming of newly created pins is also a UX issue). It would also be amazing to finally incorporate gesture controls, like in CAD software. But of course, good UX solutions are not only tricky to implement, they’re also expensive to test properly. If I could contribute to UI/UX development in some way, I’d love to experiment with new features that could really improve the experience… But that’s just wishful thinking.

The whole system for managing inputs, outputs, pins, pads, and those in-between ‘circles’ (which aren’t always clear — are they pads? Something else? Some have labels on the right, some on the left) feels like it needs a fresh take. The hotkeys for creating and customizing these entities are still confusing to me — I end up pressing them at random half the time. I can’t even imagine what this feels like for new users. Considering that, a year of constantly renaming inputs and outputs feels like a lot of effort with no real payoff. Also, so many mouse clicks that my mice are dying — that tells me there’s a problem and nobody dares to come up with an elegant solution.

I hope others will join the discussion and make arguments for or against. Because I myself am not sure that ‘it was good and it got worse’. Maybe the past version wasn’t admirable either.

Maybe the add-pin action should do a “can-connect-to-existing” check and if that fails, generate a new name. That would solve both cases you and me brought up so far.

3 Likes

But thinking about it - that “can-connect-to-existing” could feel too magical, you wouldn’t know up-front what will happen. Probably not the best idea.

Having a pop-up kind of thing for the conflicting case and asking what to do (new name, use existing) might be an option. But like you said, that would be a new UI which needs testing on its own.

1 Like

When starting out with the patch editor, one base idea we followed was that creating anything must always be possible by double clicking and bringing up the node browser. So that shortcuts can come in later. But if we go the node browser route for creating a pin with a link at hand, it seems to trigger the same “add-pin” action as the shortcut does, not asking any questions about the name of the new pin. But maybe the node browser could be a start for the pop-up idea.

In a general way, I’d say anything that makes the IDE more communicative is a good idea :-)

3 Likes

Once upon a time, I already suggested trying a new interface trick:

a

Something needs to be done about the number of clicks. Some of the ideas suggested above will both reduce the number of clicks and improve the experience in the event of a controversy. After all, the number of unnecessary clicks in the case of a ‘mistake’ is overwhelming. I think showing choices in the browser is probably not a good idea for the first choice. I like that I can create a ‘one click + shortcut’ input pin. Seems like the browser scenario would increase the number of clicks. But when the browser is called (when pulling a link from a node pin or pad) it still misses the ‘inputs and pads’ folder.

Can-connect-to-exist seems like a pretty good idea. Perhaps some experimentation and collection of corner cases is needed.

I wouldn’t worry too much about ‘magic’. Firstly, good interfaces are full of hinting. Sometimes there is so much of it that a good interface just feels ‘natural’. Secondly, the current behaviour, even though it doesn’t guess for the user, feels much more ‘magical’. It took me a year to figure out what was happening - pure magic.

1 Like

I too would like the ability to select multiple pins and set their types at once.
I disagree with adding a hovering action though.

In upcoming builds you’ll find the behavior as I described it further up - it will use a new name if the existing can’t be connected to because the resulting link would lead to a typing error.

2 Likes

There is still a problem: VVVV tries to copy the object type to the created pad.

Can you please tell me how to create these circles WITHOUT a name?

I do this 10-30 times a day. Is there a trick I don’t know? Each time I create them using the hotkeys and then delete the name. Is there a way to create them without a name?

You can just double-click → New → Pad

create_pad

Or start link → Shift Click → Delete → Enter !?

I think it’s a bit wrong in a lot of ways:
start link → Shift Click → Delete → Enter

We do it too often not to think of a way to do it less often.
Imagine: I’m moving the mouse, my other hand presses shift, I click, then I take my hand out of the mouse to press “delete” and go back to the mouse. A lot of repetitions per day. (Or I reach for the button with my other hand, it doesn’t change the point.)

This is definitely repeated more often in my practice than a situation where the name of the pad is kept.

@seltzdesign The thing you illustrate in GIF is more cursed than the thing I explain: five clicks to create and connect, and a few more to position the newly created pad.

And can you explain what the difference is between “Shift+click” and “Alt+click”? It seems like one is for pads and the other is for IOBoxes. But in the second case very often a situation arises where a huge “rectangular thing” appears (maybe this behaviour has changed recently, I just tried to stick to “shift+click” and didn’t notice).

AltClickSucks

I honestly don’t understand why no one brings this up? I’ve mentioned it several times on the forum, but it’s like everyone is fine with it. I don’t understand why. Fixing the problem would be like taking off tight shoes.

Please go here to join the discussion: Improved user experience when creating IOBoxes and Pads (including hotkeying)

Because the problem related to the topic of the track is not completely solved.