Make a simple loop to generate a list of integers [1,10] or 2D points [(1,1),(10,10)]
Make a new loop to perform a simple calculation on the elements in the first list using the Get Item from List node.
Make sure the second loop only has the one firing event from the first Build List node.
Note the first two elements in the second list are repeated and the then the rest of the elements are not in correct place in list. 3rd element is what should be in 2nd element, 9th is what should be in 10th place. (See initial output of demo composition in illustration below)
Figure 1
Now manually fire an event using the Vuo Editor either at the inputs or the output of the first Build List node (see pink arrows in Fig. 1). Now we have an even stranger output from the second Build List node, note what should be element 10 is now in the place of element 1 (Fig. 2 yellow arrow) and the rest of elements are out of place by one element (3 in 2nd place etc see Fig. 2 orange arrow):
Now fire an event at using the Vuo Editor on the Fire input port of the second Build List node. (Fig. 1 “2” with green arrow) and the second Build List node output is correct. Omitting step 5 and going from step 4 to step 6 will produce the same correct result.
This kind of element order and duplication anomaly happens using the Process List node also.
Using a Hold List node for the first list and using various fire events to the refresh port doesn’t seem make a jot of difference to this sequence of documented misbehaviors.
Have you found a workaround?
Unroll a loop and manually wire every single instance with copy and paste. Majorly time consuming for moderately sized lists, impossible for larger lists.
Other notes
Vuo version: 1.2.6-alpha2
macOS version: OS X 10.10
How severely does this bug affect you? It prevents me from using Vuo at all.
This kind of unexpected behavior, and a lack of explanation in the Manual if it’s a “feature”, makes me extremely reluctant to rely on Vuo for real work ATM.
I’ve had to unroll loops and manually wire 25 instants of a series of nodes just to work around this issue. For longer lists this isn’t even an option and given how slow Vuo gets with 100+ nodes on the editor and how hard it is to turn functioning nodes into an identical Sub-composition that just works (like making a QC macro just works) the node count rises quickly avoiding making loops.
Building and processing my own lists of various datatypes using fast C backed patches/nodes was the reason I first proposed a QC replacement. QC with JS just wasn’t performant generating and manipulating large amounts of QC structured data … so when hearing about VUO was very excited to say the least (and supportive!).
But this fundamental task for me is not working — even so far into the Vuo development as 1.2.6 — this is frustrating.
There’s not even a way to simply fire a “double event” to work around this problem that I can find. Certainly Spin Off Event(s) isn’t doing it for me. The entire event paradigm while very powerful compared with QC’s uniform pull paradigm is quite hard to debug and extremely hard to control at my stage of Vuo understanding. I think it needs work. Stepping through compositions frame by frame (and highlighting the event chain somehow in Editor) would be a start to easier debugging perhaps, but I feel like there needs to be a more user friendly abstraction over the top of it all for novice and intermediate users, I can’t think how though yet. I tried dozens of permutations of event cables on this composition to force a second fire event on the second Build List node (without going to extreme of setting up a timer and firing again after 0.1 seconds or something). I feel like a “Make Double Event” node is required just to workaround this problem I keep colliding with in my experiments with Vuo, but how to even do it, wait for the next redraw from the screen? I’m not even using a render node in this. :-)
Thanks @Kewl, well sorta. The issue I keep having is when bringing in a list of elements into a loop from outside a build list. Process List node works for one processing one list, but what if I want to process more than one list at the same time, maybe even using different indexes?
Either do parallel Process List or, if you want to process within the same Process List, maybe Merge Lists or Append Lists before feeding the Process List. If I understand what you want.
l know how frustrating it can be when you think something should work an it doesn’t. We appreciate knowing that, and we’ll look into whether we should create more examples, or how we can better clarify the documentation. We continue to work on more ways to do iteration in Vuo; we think Build List and Process List are two powerful tools for that.
In the node documentation for Build List, Built Item includes the sentence, “This port needs to receive each event fired by the Build Item port.” We can be more explicit that this port should not receive any other (external) events, which could cause the node to behave erratically. You were right to put a Hold List in the composition. Instead of sending an external event via the Share List node to Get Item from List, the first Build Item event can send the list to Get Item from List. In general, when using values and lists within a Build List or Process List loop you want to make sure all the events to access or use those values or lists come from the Build Item port.
Thankyou Jean Marie. The Allow First Event node was the trick I was missing. I did try a bunch of ways to send the event to the Hold List node when I had that connected to the Get Item in List node. Thanks also for the explanation.
Yes a “? WARNING!” breakout box with guidance around errant events coming into the loop could be worthwhile for the manual.
I think a book of ‘patterns’ in Vuo could be in order. Maybe even some test exercises like a math textbook to help gain understanding, Vuo really is a little unusual compared to other languages. With such power Vuo offers comes a little complicatedness and complexity. I’ll continue to give thought to that as I learn the basics.
Speaking of iteration, if I could author Vuo nodes (ultimate goal!), I’d be able to make versions of certain nodes like Smooth with Inertia to process lists like I did in QC using the JS patch.
If there was a way to make Stateful iterable inside Build List and Process list prior to implementing the Turn most nodes into iterators FR — it could be a stepping stone to that FR itself?
You’re right, @kewl. Using merge to (X,Y,Z,W) would get 4 values into a list to be used together — should be enough for many situations. The results can be recombined into new lists outside that loop too.
In the interest of completeness here is my original comp in working order with a minor fix (EDIT exactly same as Jean Maries post actually, I was trying other ways and ended up back at the same solution).
Explainer:
The problem was I had the event coming to the Refresh input of the Hold List from the first Build List output (i.e. from outside the second Build List loop), the intention was to load the initial 2D Point list ready for second Build List node. But an event was coming from outside the second build loop and the event got passed on to the Build Item input port of the second Build List node. This knocked out the iteration counting of the Build List node by one. The only way to solve it seems to be to have the first iteration event pass though the Hold List node because it’s coming parallel to the other nodes in the loops the events are considered to arrive at the same time to the Built Item port and no extra event is registered. Problem solved, and easy when you know how!
