This topic was brought up up in the past (e.g. here and here) and it is a great source of confusion in each beginner’s course. I really urge you devs to rework this UI bevhaviour.
Process nodes can have pins that are from operations not on update.
When they are not connected, these operations will not be executed, which is indicated on the node with a slightly different shade of gray. However, hovering this pin does not give any indication that the “Default value” that these pins have are actually not being taken into account, as the internal operation is not being executed.
Try to put yourselves into the shoes of somebody who just got to know nodes, pins, links and IOBoxes (not knowing anything about Operations). For them, a process node gets data and does something with it. “Default value” on a pin mean in this context means that this is the data the node works with. It is imho almost impossible to see that this value is actually not taken into account.
The situation even becomes worse when this “Default” value is set explicitly on the pin, but not highlighted (because it is the same value) except for the slight change of gray (which, btw, is impossible to distinguish on a projector).
try to spot the difference
the result i’m experiencing that beginners do not feel in control of what they are doing (which is the opposite of “having fun with patching”).
suggestions for improvement:
make the pin hollowed out or change its color or whatever
put a hint in the tooltip, that actually this value is actually not set and therefore irrelevant
setting the default value explicitly should also create a “pin bump”, even when the value is the same as the default value
And I thought it was just me that I didn’t get it, I felt unsure up to this day whether operations were executed or not, at some point I just discovered I had to connect an IOBox to make sure it runs … at some point it also worked without, probably because I was unsetting and setting the pin on the node. I thought the pin’s state remained the same, didn’t notice the different shade of grey and that it had an actual effect.
Never felt confident about it.
Also regarding the “Default: True” message in the tooltip. I don’t know how many hours we discussed this internally and always concluded that this message should just not appear on the node application side.
Also, all those topics came up again when developing the node-inspector…
I am a bit shocked that this still is there. Will fix right away.
thanks @gregsn for the quick response!
i just tried it in preview 5.1-199 and there is still a glitch - see for yourself:
when activating the “reset” pin the first time, the value is stored there (as can be seen when hovering), however the pin is still grayed out (as if not in use). only the second time when I do this I get the pin-bump for a stored value:
apart from this: thanks for removing the “default” indication. still, i believe the indication that some pins will not be processed should be a little stronger/more apparent, so part of the troublemaking is not yet addressed imho.
when activating the “reset” pin the first time, the value is stored there (as can be seen when hovering), however the pin is still grayed out (as if not in use). only the second time when I do this I get the pin-bump for a stored value:
well spotted, @motzi! Thanks for the report! I guess it didn’t occur over here as I was right-clicking the pin which triggers a whole different mouse event handler. Anyway. Could reproduce and finally fix it… Upcoming!
Apart from this: thanks for removing the “default” indication. still, i believe the indication that some pins will not be processed should be a little stronger/more apparent, so part of the troublemaking is not yet addressed IMHO.
I didn’t address this yet, since I fear the UI getting too verbose on negations.
I didn’t want to read anything like “operation is not called”. Wouldn’t that be distracting(?) I know @readme suggested something over here. Well, let’s just keep an eye on it. It would be very easy to add and users are boss at the end of the day.
Cool, that this is being working on, but it still is weird… from the initial state of the node I would expect the pin to be false. Then the first right-click turns it false, but indicated as changed, which then never changes when it is toggled back and forth.
I would expect the pin to be flat 50% of all cases, when the value is false, because that is the default value. Is it because the pin / the operation is not evaluated? Why can’t it evaluate always and be turned off by default?
Edit: Now that I think about it and look closer, I can see that all pins don’t return to the flat state, when they are set to their default value after they were manipulated. It requires them to be reset manually using Alt + right-click. Was this always the case?
It wasn’t the case always. Please read the original post again. The problem was that true wasn’t visualized as it’s the default.
Regarding gesture: are you clicking or dragging the pin? Maybe we can make sure that we always get a true into a Boolean when going from no value to value
from the initial state of the node I would expect the pin to be false. Then the first right-click turns it false…
All in all the following issues were addressed in the course of this thread:
setting the default value explicitly should also create a “pin bump”, even when the value is the same as the default value
default shouldn’t show up on “node-fragment-apply-pins like LFO.Reset” as it suggests the LFO is resetting
fix for sometimes value not ending up in the model (when right-dragging on a bool input instead of right-clicking it).
fixes value indicator on pin view (wasn’t reliably showing up after clicking it - instead of dragging)
clicking apply-pin the first time will enable it
Note: some of the fixed issues might have been introduced in the 5.3 previews.
Let me close the thread. This is to not mix too much into one single thread. Please take the current (preview) state as a base behavior when opening a new thread and proposing further changes. Thank you!
