i find the visualization of pad and iobox a bit too close to each other. both have the same filled circle which might be confusing. well, at least it is to me. i wasn’t sure if a iobox is also a pad since it holds data…mmm
1 Like
exaclty, it’s just data in the patch that’s why it looks the same. so an IOBox is a convenient configuration of a pad. so that’s the theory, but maybe we’ll change that since a user usually thinks differently about them, there are some discussions about that going on internally.
ok, but they are not the same, right ? the pad shows up in the nodebrowser and is a variable, while the iobox is an UI element. you can get and set a pad programmatically while an iobox is for user interaction. therefore, it is probably better to distinguish them visually.
on the other hand, if a pad can be configured as an iobox and vice versa, making them look the same, would make more sense.
I agree with u7 that there is a unnecessary confusion between ioboxes and pads.
as far as I understand, IOboxes are currently constants, their values are compiled into the running patch. so my take on fixing the confusion is to make them actual IOBoxes, that transmit their current user set value to the concurrently running patch, instead of triggering a recompile each time they are changed. I respect that you thought it feasible to cut a corner here, but it does seems an obstacle now more than a long term solution to IOBoxes. please correct me if my observations and guesses are incorrect.
of course, a different visual would be helpful to communicate this change. a tiny eye&hand as a logo maybe, depending if used as input or output or both?
this also means that the user option to exchange pads for ioboxes are more involved to accomplish, so my (definitely also more involved) wish would be to upgrade that mechanism to still allow this handy exchange, and also allow exchanging to/from Inputs and Outputs. Because that is often necessary, once a sandboxed algorithm prototype is turned into a operation or method.
a change like that also means that there’d be no such thing as a compiled constant in a patch. this sucks, because there are cases, where you would want a fast constant. however, since this is also kinda unsolved for Operation, I would argue for sacrificing that for the time being, until a more universal solution for expressing const visually is found, like one where you can also express ½√3 in a legible way without having to recalc that each frame. in my mind that is like a Cache region that only executes once like some kind of precompiler and can be used like it is completely stateless.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.