Data only cable type

Currently we have 2 types of cables:

  • event and data
  • event only

It would be cool to be able to simply strip the event away from cables, thus adding a 3rd type of cable:

  • data only

This would make it easy to retime data (resample) and also stop mix ups with event firing if you have multiple event and data cables connected to same node.

Currently I use a hold.value node to achieve this. (Maybe I am doing it wrong?)

Also if we remove the Refresh port on nodes then this makes understanding event flow in Vuo more important. (Which is a good thing). What I mean to say by that is that you have to then understand where your events are coming fromā€¦

Currently I use a hold.value node to achieve this. (Maybe I am doing it wrong?)

No, thatā€™s the right idea ā€” until ā€œthe ability for composition authors to override portsā€™ event blocking behaviorā€ from feature request Allow feedback loops without needing a Hold Value node.

For retiming data and managing multiple event streams into the same node, the concept of a wall (event blocking) already handles that.

There is one situation where we do plan to add data-only cables: feature request Ability to detach constant value flags and connect them to multiple nodes. The data would automatically travel from the detached constant to the connected input ports when the composition starts and when the constant is edited.

@alexmitchellmus, have I missed anything in understanding your request for data-only cables? Or is this feature request already covered by the others I mentioned?

Thanks @jstrecker!

Yes all looks good. Can the current requests be simplified? I think that ā€œData only cable typeā€ is simpler language.

On second thought, something like data-only cables (or the ability to add a wall to the end of a cable?) might actually be something to consider separately from the FRs I mentioned. Team Vuo will ruminate on it.

1 Like

:-)

I think if data-only was implemented then it would make sense to use a dashed (dotted) cable: thin for event- thick for both- dashed for data (it would even look like ants connected together- which is kind of what it is!) Ā 

So, Iā€™m thinking of a data-only cable as another way in the Vuo language to express event blocking.

We already have the idea of walls. Based on the experiences of various people including myself, Iā€™d say that walls are not flexible enough. To add a wall, you have to add an entire node (Hold Value). If thereā€™s a wall where you donā€™t want one, you have to add extra cables to circumvent it. I hope we can improve upon walls in a way that makes the Vuo language more usable and readable.

On FR Allow feedback loops without needing a Hold Value node, thereā€™s the proposal to enable adding/removing walls on individual input ports.

Data-only cables would be a different solution to the same problem. In terms of walls, Iā€™m thinking of a data-only cable as behaving as if it had a wall attached to its right (input) end. Data-only cables would be enabling event blocking per-cable, not just per-port.

How common in practice are event-flow problems that could be solved with the added flexibility of per-cable event blocking (data-only cables) and not with per-port event blocking? Can data-only cables and walls coexist in the language, or would it be too confusing to have multiple ways to express event blocking? I donā€™t know.

@alexmitchellmus, what do you think?

Hey @jstrecker, I think event blocking may be clearer with a cable, as there are already event only cables, that makes sense to me.

However I think its up to the community, and possibly it may be something that once implemented we will notice if it works or not.

Saying that, I do personally think that both cable, and port event blocking could work, considering that we are ā€˜forcingā€™ a block with a data-only cable- and it would be very clear to the end user (as the cable would look unique).

I think port socket shape variations could add to readability. Iā€™m certain line-types by cable object-type would (event-only, single object data+event, lists, one day lambdas!). Theyā€™ve been standard in complex engineering, maps and architecture drawings for a very long time because they work.

I was never a fan of the protruding ports, even though I understand the reasoning behind the decision (making cable-port connections more obvious than in QC) I think itā€™s debatable if the logic holds water. To me it can still be hard to see if the angle is close to perpendicular and that could be rectified by making the cable arcs enter ports at a horizontal angle.

Various shapes that ports could take if they were rather than outside nodes but inside ports but open and on the edge would be triangular (normal), square (data), circular (lists and lists of lists), hexagonal (four sides of the hexagon) (events). Or any other permutation. (I donā€™t like the aesthetic of it though so far).

Colouring wires (either randomly or by type) on selected nodes could improve readability as well as dots for events and dash-dot for lists. Although if screen notes or expanded sub-graphs (window-in-window that doesnā€™t exist yet) had coloured backgrounds that could make random colours problematic for readability.

Ā 

Opened for voting. (Finally!)

This feature would make it possible to change any data-and-event cable to a data-only cable.

This feature would build on (and greatly extend) the inklings of data-only cables that currently exist in Vuo:

To minimize confusion, the data-only cables for this feature request would behave the same as the existing data-only cables.

  • When the data on the output port changes, the data on the input port immediately changes to match.
  • The node attached to the input port does not execute as a result of the change. It only executes when it receives an event (from a data-and-event cable, event-only cable, or manually fired event).

To support whatā€™s reported in the first point above, this FQ could be useful not only to allow to drag data-only cable, but also to visually highlight the already existing situations where event donā€™t pair with data changement. Itā€™s exactly what happens changing constant published data in user defined subcomposition; documentation tells about that:

The data travels from the published input port to any input ports that are directly connected to it by a cable. This is a rare case in which data can travel without an event. The data reaches the input ports on nodes but does not cause the nodes to execute.

I suspected a bug when my subcomposition behave differently if i changed this:

to this:

They visually look similar, but they arenā€™t, as in the first example new values dontā€™ exit the ā€œshare valueā€ node. I was fooled by the ā€œdata and eventā€ cable running from Value published port: because it is in realty a ā€œdata onlyā€ cable.

I think that a way to visually show it, that automatically is applied in such a case, would give a correct feedback of the behaviour.  

1 Like