Support changing both C nodes and subcomposition nodes.

vvvv equivalent: 

Spreads

Component: 

Notes from Team Vuo

Vuo Pro: 

No — available with both Vuo and Vuo Pro licenses

Complexity: 

●●○○ — A few weeks of work

Potential: 

●○○ — Appeals to current community

Tentative plan:

  • Be able to turn one or more of a node's input ports into a list to iterate through.
    • If an input port is turned into a list and sent N items, then the node executes N times and outputs a list of N items.
      • Example: Subtract node's A port is turned into a list and fed [91,81,71]. B port is fed 1. Output is [90,80,70].
    • If multiple input ports are turned into lists and sent N items, then the node executes N times and outputs a list of N items.
      • Example: Subtract node's A port is turned into a list and fed [11,22,33]. B port is turned into a list and fed [1,2,3]. Output is [10,20,30].
    • If multiple input ports are turned into lists and sent different numbers of items, then the node executes for each item in the longest list (similar to Copy 3D Object).
  • Support both regular and generic port types.
    • If a generic-typed input port is turned into a list, all of the items in the list will stay the same type.
      • Example: Make Sphere node's Material port is turned into a list. You can change all list items from type Color to type Image. But you can't change some items to Color and others to Image. (Instead, you could change all items to Shader and connect Shade with Color and Shade with Image nodes.)
  • Support both stateless and stateful nodes.
    • For a stateful node, keep track of N separate instances of its state.
      • Example: Count node's Increment port is turned into a list and set to a constant value of [4,5,6]. On the first Increment event, the node outputs [4,5,6]. On the second, the node outputs [8,10,12].
  • Support both regular (C) nodes and subcomposition nodes.
    • Subcompositions and node implementations don't need to do anything special to support iteration. Vuo will keep track of executing them at the right time with the right inputs.
    • Support for subcompositions enables loops-within-loops.
      • Example: Subtract node's A port is turned into a list. Subtract node is wrapped in a subcomposition called Subcomp, with all of its ports published. Subcomp node's A port is fed [403,503,603]. Subcomp node's B port is turned into a list and fed [1,2,3]. Subcomp outputs [[402,502,602],[401,501,601],[400,500,600]].
  • Feature request Lists within lists will be required to support nodes with list outputs ports and turning a list input port into a list-of-lists.
  • Feature request Select and OSC nodes with variable number of ports will be required to support nodes with event-only output ports and nodes with door input ports.
  • Beyond the scope of this feature request / could be a separate feature request:
    • Turning an input port on a drawer into a list. (Instead, you could wrap the node in a subcomposition with the drawer port published, and turn the subcomposition node's input port into a list.)
    • Turning an input port on a node with trigger ports into a list.

Comments

A couple of questions from

jstrecker's picture
Submitted by

A couple of questions from the Vuo community have led back to this feature request.

On Create multiple instances of stateful node, Teo asked if there's a way to create multiple Syphon servers, multiple windows, etc. without having to put multiple copies of the node on the canvas.

On Smooth List Values, Bodysoulspirit asked if there's a way to smooth the changing values in lists, for example the output of Calculate Amplitude for Frequencies.

In both cases, the problem can't be solved with a Process List node. One possible solution would be a specialized node to handle the specific problem (e.g., a Smooth List node). A more general solution would potentially be this feature request.

Is there any chance of this

smokris's picture
Submitted by

Is there any chance of this working for list within list? (When list in list is implemented?)

Ideally, yes. (We haven't done all the technical planning for this feature request yet, though, so I can't promise it will be within the scope of this feature request.)

this sounds exciting — but

useful design's picture
Submitted by

this sounds exciting — but daunting also. I can imagine making nodes to produce multidimensional matrix shaped data (lists with structure instead of list with items containing many elements in a row). this could present issues but I suppose if the datatypes I create just cannot be passed to certain other nodes that will be alright. Hmm this is hard to think about until i become a more advanced Vuo user. (i.e. until i move beyond novice)

Hi guys. I'm seeing a lot of

Bodysoulspirit's picture
Submitted by

Hi guys. I'm seeing a lot of discussions and questions on the Vuo website about Building Lists, Processing Lists, spreading objects, manipulating each objects in the list separately, my question about smoothing lists etc etc.

I have already pledged many votes on that feature request by Steve. I find iterations in QC were not so easy to handle, and considering the amount of questions regarding iterations on the Vuo site, I think much people care about easy but deep possibilities.

So before I spend more votes on it, I would like to submit the team some questions about what is planned to be possible with that and what not (see mockups below) and discuss with the other members what they long for regarding iterations.

Thought I could discuss this here as the notification system on the site not yet is completely implemented and it seems most people active on the website are available here on Facebook. I could want to copy paste the results on the related feature request page though.

So the first 2 questions I have are shown in the mockups below (excuse the poor design of the mockups guys, just made them in Keynote ;)).

1/ Will some node like f.e. "Make color Layer" accept 2 list nodes and be able to handle these in order to manipulate the child objects specifically.

2/ Mockup B is of the same kind but has a "Make Points Along Curve" node attached to the 'Phase' port of a "Wave" node.

Hope anybody wants to join the discussion.

1/ Will some node like f.e.

jstrecker's picture
Submitted by

1/ Will some node like f.e. "Make color Layer" accept 2 list nodes and be able to handle these in order to manipulate the child objects specifically.

Bodysoulspirit, that's an interesting question. To make sure we're on the same page — are you thinking that the Make Color Layer node would execute N times (using the 1st color and 1st center, then the 2nd color and 2nd center, ....) and output a list of N layers?

Possibly Nodes handling multiple lists to input ports need to dynamically add a input for determining iteration count

Alastair, the iteration count could be based on the number of items in the longest list, similar to Copy 3D Object.

@jstrecker yes totally what I

Bodysoulspirit's picture
Submitted by

Jaymie yes totally what I have in mind.

And with the other image I'd expect "Make Points along Curve" to create a list of "Make Wave" nodes having all different phases to rotate the different layers independently.

And if those wave nodes would have been connected to the layer's center node instead of rotation, I'd expect x layers to move on the window, from left to right, each one with it's own phase (sorry the wave node is wrong on the mockup).

Real Iteration ;)

Could the title perhaps be

Bodysoulspirit's picture
Submitted by

Could the title perhaps be updated to something like Iteration : Turn most nodes into iterators by allowing single-value ports to accept lists ?

Iteration at the beginning of the sentence so people know what this is about at a glance. Maybe important when you realize how many questions and problems are related to build list and process list

Have already casted quite

Bodysoulspirit's picture
Submitted by

Have already casted quite many votes on this, plan to cast more as this will add an amazing amount of possibilities !

However, I'll wait for the team to "do all the technical planning for this feature request" to cast more.

For example "What data types will accept lists and which not ?
Or which specific nodes won't accept lists ?

Very important Feature Request so I really hope all those people having questions about build-list and process list and all those having exceptions for deep Iteration to join the discussion !

The more details we will have on what you people hope for this and the more details we receive from the team on what is possible and what not, the better !

@Jaymie thanks.

Bodysoulspirit's picture
Submitted by

Jaymie thanks.

Feature request Lists within lists will be required to support nodes with list outputs ports and turning a list input port into a list-of-lists.

Does that man my above question "smooth list values", f.e. connect Calculate Amplitudes for frequencies to a Smooth with duration node won't work ? Or do you mean nodes with output drawers ?

If multiple input ports are turned into lists and sent different numbers of items, then the node executes for each item in the longest list (similar to Copy 3D Object).

Great start ! Enough for the scope of this FR ! Guess in some feature a separate feature request could be made to specify how each port could share the other lists ? Could get very complex I guess but I can imagine some like "set a reference list" and then options like "spread and equally share the list, or fill, or cut ...".

Beyond the scope of this feature request / could be a separate feature request: Turning an input port on a drawer into a list. (Instead, you could wrap the node in a subcomposition with the drawer port published, and turn the subcomposition node's input port into a list.)

Ain't that part of "lists within lists" too ?

Does that man my above

Bodysoulspirit's picture
Submitted by

Does that man my above question "smooth list values", f.e. connect Calculate Amplitudes for frequencies to a Smooth with duration node won't work ? Or do you mean nodes with output drawers ?

I realized later yesterday I surely had been talking trash here. As Calculate Amplitude for Frequencies is the mother node and not the child node, and Audio Samples already are lists.

However, Smooth with Duration has a door on time. Does this mean the node won't work ?
Won't nodes work as soon as one of their ports have doors or events, or will we able to use those nodes, but not turn those specific ports into lists ?

However, Smooth with Duration

jstrecker's picture
Submitted by

However, Smooth with Duration has a door on time.

Bodysoulspirit, that shouldn't be a problem. Iterating over Smooth with Duration N times will be equivalent to putting N copies of Smooth with Duration in your composition. The iterations will handle the door just as the copies would. (Below illustrates the copies.)

Ain't that part of "lists within lists" too ?

It's a little beyond that. Currently all of a drawer's input ports have to have the same data type, and the output port is a list of that type. So we'd have to figure out how to implement a drawer where some inputs ports are one type and some are a list of that type.

@timwessman agree with that.

useful design's picture
Submitted by

timwessman agree with that. While stateful nodes will work in Process List (like say a count patch can count through the iterations) you can't iterate the stateful node itself which is where its at for this FR I think.

Here's 25x Smooth with Inertia unrolled onto the canvas. Makes the Vuo Editor slow down I suspect… (also until we get this FR, if VUO copied wires on ports to the "Option + dragged" nodes it would save a bunch of time wiring back to the shared value nodes, and in a special case of copying output wires to Drawers, duplicate the wire and add a Drawer port if necessary).

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 vuo.org
  • Reviewed by Team Vuo
  • Open for community voting
  • Chosen to be implemented
  • Released

Votes

313 votes so far!
Vote

Who voted?

luciano's picture
groovdam's picture
botnotbot's picture
Jérôme Lanon's picture
Kewl's picture
w4tcher's picture
thomasebartley's picture
mixfilet's picture
useful design's picture
krezrock's picture
alexmitchellmus's picture
Bodysoulspirit's picture
milliondots's picture
MartinusMagneson's picture
kyrrelys's picture
TyParks's picture
visiophone's picture
timwessman's picture