Why are iterators in VUO so hard to get to do what you want and is there room for improvement?

Driving me crazy trying to do simple calculations on lists of numbers that I can’t do in Calculate List nodes because the calculations refer to items of multiple lists or lists of multidimensional values or using different indexes on different lists at the same time in calculation. So calls for a roll your own loop.

But trying to use Process List and Cycle Through List (which does provide an iteration index number at least) is just so hard to get to work. Trial and error going on for hours looking for ways forward, and I understand the need for Hold List to block events to the loop which was my first stumbling block last time I had a go at doing something useful in VUO.

Things I could do in 5 minutes in Javascript, QC Iterate patch (or 20 minutes in any other new language I haven’t learned yet) taking hours and still no result. Super frustrating Team Vuo. Need more examples of more interesting loops I think to crib from.

Part of the problem is that even Show Events doesn’t break down a cycle of iteration events inside a loop. Maybe it needs some other way to show events inside an iteration rather than just one blink per complete cycle? Another part of the problem is that there isn’t a way to log info to the console, the way I usually debug and comprehend mysterious happenings. It’s easy enough to pass some simple text to the Console (say a 3D point using a string of 3x point list to real conversions to real list to text list to append text with separator), but it’s not possible from what I can tell to log to Console say a list of 4D Points, we need to use the tool tip windows. I discovered you can print to console inside a loop but only if it’s working as it should.

I guess I’ll go and vote for the Python/JS/Lua node FR, I don’t have time to learn enough to write a custom node in C ATM but I’m sure the iteration part of it would be easy.

Don’t use process list for items you need an index for! The Build List is more suited to those things as the item output port gives an index number.

Thanks @MartinusMagneson, I was trying to remember the third list making/processing node. I’ve been mucking around with Cycle Through List because it has a position output. But I figured I needed Process list to drive the events to it. The output going to console is confusing as hell and quite different going into an enqueue node than back into the processed time port of the Process List node. Finding it all very discouraging. The math is trivial, the stupid Vuo is mindbogglingly tricky until you know the how and why in great detail. There’s no clues to the subtleties of why an event has go to the triangle input of the hold node rather than the fire port of the Process List item.  

@MartinusMagneson, thanks for your helpful answer.

@useful_design, I want to bring this discussion back in a constructive direction. I understand you’re frustrated and I agree that Build List and Process List can be tricky to get working for non-trivial situations. A lot of people have had the similar questions. If you look for past discussions on Build List and Process List, you’ll see several times where someone shared their composition and asked how to get it working, and with the community’s help they were able to. These nodes are admittedly not the easiest to use, but they do get the job done if you’re willing to have the patience, and they’re hopefully better than nothing. Please bear with us until we’re able to implement a more robust method of iteration.

While I and the rest of Team Vuo welcome suggestions on how to improve Vuo, or even measured comments on what you found difficult to learn, your recent comment comes across to me more as venting. I really am sorry that Vuo is falling short here. But that kind of comment is just not constructive or helpful toward solving the problem.

I think you’re on the right track to be using Display Console Window in your debugging attempts. Without seeing the composition, I’m not sure why it’s not working as you expect. Maybe if you post your composition someone can help.


Yes just wanna add my 2 cents and say I understand both Alastair and Jaymie here !

Sometimes also I wonder why some things in Vuo were done in a specific way I find complicated, and yes sometimes I wish for easier methods but yet also more powerful ones, struggling very often with limitations like iterations, accessing iterated elements, or iteration on list elements like Kewl’s question about the Calculate List that could have more then 1D (x) elements or Pianomatic’s question about allowing more data types in the calculate node, I miss particles also and Depth peeling.

But we cannot complain in an aggressive way and require a software that is created by other people and whose purpose and features are oriented by a whole community to work exactly the way we want it.
I guess if we want things to change we either 1) learn to code and do it ourself or 2) pay the team to do it or 3) gain votes by uploading stuff and by buying updates to vote for our feature requests.

I came to Vuo some years ago because on the Roadmap it was written “Export to Screensaver”, then the roadmap was removed and we had the voting system (which is great). My dream always was to make great screensavers. During these last years I could have learned to code, but I hate to code. I spent hours playing with Vuo and uploaded several things and voted for the screensaver option and yesterday I read it was chosen to be implemented …

Beside that, I came for the screensaver, but I discovered a great community and moreover an amazing team !
I don’t know any other software company that is based on feature requests by the community and who works so closely with the users ! Answering fast, sometimes even creating compositions for you.

Discussions & suggestions work, feature requests work (had several implemented), great ideas are voted for.
But yeah some things take time and we wish some things were added faster. Keep in mind that as the team said they fund Vuo personally by 80% so the team’s whole work time is not spent on Vuo.

That’s the threshold to find, the more features the more users, the more users the more funding, the more funding the more time they can spend on it, the more features we get …


1 Like

Hi @jstrecker yes I was totally venting here. My apology to you and everyone for that.

Was venting not just for my own frustration but frustration at my perceived threshold of pain for new users to get acquainted with Vuo and hopefully buy it and start using it and foster the community. I’m used to coding thresholds of pain, I’m not a natural, currently learning Haskell mostly on my own and did same for JS and Python several years ago. But I’m also used to having strategies to go very simple and build my own how to do examples and working up the complexity until I achieve my goal and in Vuo I find this a difficult strategy.

The demo examples are a great help I must say, but when they don’t cover it, you really are out on your own.

I posted my problem compositions (three stages of working through the problem) to another thread and got no response. Two words: “Build List” was all I needed to hear to move in the correct direction, although from an academic/new-users POV the weirdness of the outputs of those other compositions did allow me to experience some negativity about the current Vuo approach to iteration.

The great news is I now understand how to use print to Console inside loops and outside loops to diagnose issues where the Show Events function can’t get inside the loop and make it clear what is going on that is problematic. Perhaps I can make a tutorial forum post or video on that for new users if that would be helpful.

On Kineme forums I patiently helped dozens of new users get acquainted with the nuances of QC and Kineme plugins by answering questions, fixing composition bugs and incomplete solutions where I could. And on the FB groups for QC & Origami for some time. And I’d be more than happy to do same in Vuo if I could reach a similar level of competency and that kind of community evolves for Vuo.

I got it solved with the Build List nodes after @MartinusMagneson mentioned the magic word ‘Build’ in about twenty minutes. It did take some careful use of print to console node for me to figure out the nuances of event flow, I had and extra event coming into the loop from the Hold List node because I needed it not just going into the Build List node but into a Get Item from List node and this meant I was getting an extra (duplicate) output in the list in console (but not from the Build List node) . So I needed an additional Hold Value node at least to make sense of the Console output if not the composition itself (the extra event made the offset pattern shift by one but the Build Node limited the output to required number of items in list).

It’s at least six months since I used Vuo and had forgotten Build List exists, when you type "list" in the Library, at least in my version Cycle Through List comes up first and Process List comes up second, Build list comes twelfth and I’m sorry to say I didn’t see it. Does the node library prioritise node order according to user previous usage?

When I type Process I only get that node and Split Audio by Frequency. Although when I type cycle I get cycle, process and build as the top three, unfortunately for me I wasn’t typing cycle when I started looking for the third list making node I vaguely remembered something else exists. An yeah I don’t use the manual because it’s more of an intro to Vuo than a reference book, and searching it now for Iteration yes I would have found Build list in the (); note for text programmers breakout box.

Suggestions: add “Process List” to the metadata for Build List so it appears in Library when someone types “Process” in the node Library. If there’s a simple way to make Build appear in top three suggestions with Process and Cycle when you type list that could be helpful for new users too.

I’m happy for you to delete this entire thread if it leaves a bad taste or risks putting someone off Vuo. I wouldn’t want that for anything, and I’m very appreciative of what Team Vuo does to advance this tool, what Vuo can do already, and what Vuo will evolve to become. It’s been a long journey since the early days of pre-Alpha Vuo and I’m still as hopeful I can use it for more than fun projects one day.

The first example composition LINK (6 KB) still has an extra event going to the Console Window because I reset the Count node with an event from the Built List port. In the second composition (6.18 KB) I do it another way so the Count node never resets (the iteration index still gets wrapped in the Limit to Range) and so that extra event doesn’t happen and so it doesn’t register (in a potentially confusing way) on the Console Window.  

Didn’t realise Build List outputs a number as well as an event for each item counted in input list. So this version removes my Count node for simplification. Still struggling to work with multiple lists which influence each other (two way).

WORKING iteration with build accessing other items in list.vuo (5.94 KB)

Referring to the underlying tension, I think it is good to be able to have a discussion like this. But venting itself isn’t really constructive - although it can be necessary at times to clear the head. I find it a lot better personally, if it comes to it, to write everything I’m frustrated about in my own foul language in a Word document. Then I take a trip outside, have a coffee, read my words, laugh at it and delete it. The problem with saying f-you to Powerpoint is that Powerpoint doesn’t really care. If it cared, it would still have done exactly what I asked from it (albeit maybe a bit sweaty) - not what I really wanted to ask from it, as it is a computer application.

When I’ve calmed down, I can formulate my challenge in a way that is not offensive and more to the point to someone that has the ability of caring. They might not though, depending on the issue being for 1 in a million (nah), for 1 million (yup - in a year or so), or out of interest (maaaaybe?). If you are at a point where your challenges are not regarded as important either from a business or interest point of view, there are some options. You can ask for help with the challenge, do the adaptation yourself, get someone to do it for you, or look for a different solution.

With my venting-venting done, switching over to your challenge, the main point to understand in Vuo as far as I see it is that Vuo is push in opposition to QCs pull. When that is understood on a more fundamental level, a lot of the other mechanics in Vuo is a lot easier to understand and “get” - including the Build List. Pulling sees everything that is connected to the output and drags all the calculations down to calculate the result. Push on the other hand is a way to operate that kicks the data and events downstream from a starting point, to the end result. Where pull can be quite resource intensive, push gives you the ability to have greater control of what gets calculated when. This comes at the cost of complexity, but is what makes the Fire on… and Hold nodes both frustrating and great at the same time.

Thinking about it as streams and rivers may help to visualize the flow. Start out with three lists, these are your streams. Add a Build list node, and hook up three Get Item From List nodes from the Build Item port to the Which port. Combine or process your original lists, and output the result through the Build List node. This is your river.

This is the smallest example I can think of, but all the essentials are there. The input to the Hold nodes needs an event (Fire on Start), the Hold node needs an event (Build Item), and the Items port need an index (Build Item). This is how Vuo knows to push the data, and where to push it. If there are no event, nothing has pushed the data to the port, and you won’t get the desired result. If there is no Index, Vuo won’t know what to push (or it will know, but it will probably be the wrong one for what you want).

Shortcuts and what-does-what! This is practice and memory, nothing more. A few tips to make it smooth is cmd-enter to go into the library. The filtering system can be a bit itchy when you’re not familiar with all the nodes and what they do, but to look at the available options in a certain set, you can type [nodecreator].[nodetype]. For “vuo.list” it will filter out anything but the stock list nodes for instance, “vuo.math” will list all the stock math nodes, “co.parabox” will list all of Karl’s nodes, “stv.” will list all of Satoshi’s and so on (if you have those installed that is).

You also don’t need to complete each word in the search bar to find your nodes. “bu li” for instance will pop right to the Build list. “r s w” will go straight to Render Scene to Window, and “r i w” will give you Render Image to Window. You can also define more letters to be more certain the correct one will pop up. “s v” will go to Share Value, but “sp v” will take you to Spin Off Value. Getting the brain-/muscle-memory right there take time though!

(Oh, and next time you get frustrated with an application not doing what you want, try setting up Powerpoint on a MBP with presenter-view on three screens feeding a BMD switcher. Nothing will make you search faster for the hypothetical g d t u p o s node)

1 Like

Thanks for taking the time to respond, Magneson. It was your earlier suggestion to use the more appropriate Build List node that got me arriving a a solution. I’d forgotten that Build List was one of the main three looping nodes (and when I typed List, cycle through list and Process List are the first two, but build is down at no 12 and I missed it repeatedly).

Having said that the strangeness of outputs I was getting from a combination of Cycle Through list and Process List was pretty weird using a console window to look inside the loop in the hope of debugging my concept. Just got very confusing not knowing what was happening with events inside the loop which are not shown with “Show Events” Maybe we need a “Show Events inside Loops” preference or button which blinks them in a different colour?

My issues were to do with operating data that updates, so loops that operate on last state of the list, that’s a bit more complex than building a list from scratch, especially if you are referencing more of the data than at the current index, hence the need to use the count number and add one to it to get some of my values, including wrapping the values that exceed list length.

When I get a chance I’ll finish the composition and post it, was just an exercise I hoped I could do easily in Vuo.

Thanks for the tips on searching the Library using initials too.

I get the push vs pull dynamics, and the advantages that offers for computational optimisation. It does present some tricky issue though especially if you have some data updating every frame and other data updating, say, once every second. We need to make sure extra events don’t sneak into the Build List loop and upset the order of items returning to the Build List node which will corrupt the build and make for very confusing outputs.

I’m still not confident with getting that right from the start with lots of debugging and demo coding.

Live and learn :-)