Support changing both C nodes and subcomposition nodes.
vvvv equivalent:
Spreads
Support changing both C nodes and subcomposition nodes.
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.
If anyone would like to help this happen sooner, we're also accepting open source contributions and commissioned work.
Read more about how Vuo feature requests work.
Comments
A couple of questions from
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., aSmooth List
node). A more general solution would potentially be this feature request.This sounds very exciting!
This sounds very exciting! Is there any chance of this working for list within list? (When list in list is implemented?) So that even list nodes could be iterated?
Is there any chance of this
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
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
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.
12764408_1674165136177737_6725765704190838093_o.jpg
12493624_1674165139511070_1811198364715322909_o.jpg
Possibly Nodes handling
Possibly Nodes handling multiple lists to input ports need to dynamically add a input for determining iteration count, so settings choices might be:
max list length
,min list length
,specific integer
? Maybe I'm suggesting unnecessary complexity?1/ Will some node like f.e.
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?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
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 ;)
@Bodysoulspirit — That sounds
Bodysoulspirit — That sounds good to me.
Could the title perhaps be
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
andprocess list
@Bodysoulspirit, sure.
Bodysoulspirit, sure. Changed title.
Have already casted quite
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
andprocess 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 !
Very interesting! My 2¢: It
Very interesting! My 2¢: It needs to be equally easy to address the individual input for item N as it would be to create a phase-shifted list addressing the iterated item inputs. That is also, I suspect, the hard part without relying on huuuuge drawers. Will wait for more info!
I just added some details in
I just added some details in the "notes from Team Vuo" section. Bodysoulspirit and Magneson, does that answer your questions?
@Jaymie thanks.
Jaymie thanks.
Does that man my above question "smooth list values", f.e. connect
Calculate Amplitudes for frequencies
to aSmooth with duration
node won't work ? Or do you mean nodes with output drawers ?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 ...".
Ain't that part of "lists within lists" too ?
Still I'm voting 10 more
Still I'm voting 10 more already ;)
Does that man my above
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
Bodysoulspirit, that shouldn't be a problem. Iterating over
Smooth with Duration
N times will be equivalent to putting N copies ofSmooth with Duration
in your composition. The iterations will handle the door just as the copies would. (Below illustrates the copies.)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.
copies equivalent to iteration.png
@Bodysoulspirit, that shouldn
Cool ;) I'm voting 10 more (all I have left) ;)
I think iterating stateful
I think iterating stateful nodes is the most important feature i'm waiting. I have already put 25 votes for this and now again my last 6 votes.
@timwessman agree with that.
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).
Screenshot 2017-07-10 09.49.52.jpg