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...


Notes from Team Vuo

Vuo Pro: 

No — available with both Vuo CE and Vuo Pro


Currently I use a hold.value

jstrecker's picture
Submitted by
Feature status:
Waiting for review by Team Vuo
Waiting for more information from reporter

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?

I think if data-only was

alexmitchellmus's picture
Submitted by

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

jstrecker's picture
Submitted by

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 @Jaymie, I think event

alexmitchellmus's picture
Submitted by

Hey @Jaymie, 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

useful design's picture
Submitted by

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!)

jstrecker's picture
Submitted by
Feature status:
Waiting for review by Team Vuo
Open for community voting

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).

Feature status

When we (Team Vuo) plan each release, we try to implement as many of the community's top-voted feature requests as we have time for. Vote your favorite features to the top! (How do Vuo feature requests work?)

  • Submitted to
  • Reviewed by Team Vuo
  • Open for community voting
  • Chosen to be implemented
  • Released


5 votes so far!

Who voted?

cremaschi's picture