- Mac OS 10.10
How severely does this bug affect you?:
Steps causing the bug to occur:
- 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)
- 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.
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. :-)