Support changing both C nodes and subcomposition nodes.
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.
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 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 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 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 @smokris. 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.
Â
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. â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 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 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 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 !
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 the ânotes from Team Vuoâ section. @Bodysoulspirit and @MartinusMagneson, does that answer your questions?
1 Like
@jstrecker 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 ?
Still Iâm voting 10 more already ;)
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 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.
1 Like
@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.)
Cool ;) Iâm voting 10 more (all I have left) ;)