I'm beginning to find that with an increase in Vuo composition complexity comes an increase in the unwieldiness of working with
Build List and
Process List nodes. I was thinking of putting together a feature request, but given the plethora of potentially upcoming changes to lists, I thought a discussion might be a better venue in which to start.
Here are the issues I'm finding, along with workarounds and possible Vuo Editor improvements.
Too many required
Hold Value and
Hold List nodes
I'm working on a composition that has, in three cases, ten
Hold nodes (five with lists) to go with a
Build List node. Why so many? To improve performance, the composition crunches some numbers upon launching rather than with each requested frame. The result is lots of saved values coming in via these
My workaround I could (but won't) give up some maintainability by hardcoding in some of the values.
Hold nodes are required for event management when building or processing a list, this behaviour should be automatically provided. Perhaps when one connects "outside" data to a node "inside" a system of nodes building/processing a list, a hold node (and the appropriate cable connections to make it work) could be automatically inserted, in the same manner that conversion or rounding nodes can be automatically (or nearly automatically) inserted.
Events management with incoming data
I have two lists that are built in parallel upon launch. Both of these lists are then used, in conjunction with
Hold List nodes, to provide data in the construction of another list. Because both of those "feeder" lists generate brand new, unrelated events, I cannot reliably execute the
Build List node at a moment in time when both feeder lists are complete. Roughly half the time, one or two iterations of the latter build are run before the incoming data is available.
Abandon the idea of generating data in parallel and do it in series. Or set things up so the latter
Build List node executes when (and only when) a specific number of events have arrived at, say, a
Count node. The first suggestion is almost certainly the most suitable in most cases, for maintainability, but it would be so much more slick to be able to do them in parallel.
The best solution for me would be to have the
Built List output port fire not a new event when the list is built, but the same event that arrived at the
Fire input port. That way the events arriving in parallel will wait for one another before moving forward. An alternative solution would be to somehow give the
Build List node some way to keep track of the data required to build the list, and only execute once all the required data is received. (This second suggestion has the potential to open up a new can of worms, though, since some data required may not arrive as frequently as is required for the build, as some data could keep the same value for a while.
Debugging is very difficult when building/processing a list
My issue Clicking on a port within a build system displays only a single value at a time. When a 100-item list is being processed, it's impossible to look at individual pieces of data in place.
Connect the output port of a node within a build system to an
Enqueue node. (The output port of the
Enqueue node leads to nowhere, but can be used to have a look at more than just a single value.)
Potential solution Enable a user to click on a port within a build system and see a list of values, matching the functionality of my workaround, but without the extra node.
...what are the current plans for
Build List and
Process List? Are they going to remain as is, or are we going to start seeing nodes that we can "dive into", like QC's Iterator node?