- Prefers to be called
- Uses pronoun
- Perth Australia
- 6 years 9 months ago
- Last seen
- 2 weeks 2 days ago
Thanks Jaymie Vuo 1.3 is going to be a mammoth release by the looks of it.
Please consider 'macros' or Group Nodes as a high priority for composition tidiness, and I suspect for Editor run time performance too? To my way of coding it's as important for legibility and coder comfort level as the canvas notes (which will be coming in 1.3 I believe, exciting!).
On the Modules folder, would all Vuo compositions in any given folder share access to the Modules folder? In one sense this is a feature (shared non-global scoping of sub-comps) in another way it's a kinda a potential liability: each Vuo comp (including version saves which is how many of us save our work) with sub-comps would require its own parent folder to maintain single Vuo file scope for the sub compositions.
Team Vuo have probably thought it all through better than me, but that did occur to me as a potential issue. I guess it's better than embedding the sub-comp file in the Vuo file though which was how I kinda assumed it would work.
This composition is a bit more complex, but it uses position (in polar co-ordinates), velocity and acceleration to move an autonomous car around a track. It just uses Hold Values and calculations to do the maths, most of the other nodes (grey) are additional stuff for screen printing data and converting the polar coordinates to cartesian coordinates. Unfortunately we can't hide them away in macros just yet.
Look for the "tangerine" coloured nodes, they do all the work and there's only three holds and three calculate nodes one of each for each variable (position (θ), Velocity and Acceleration).
You'll need to relink to this image for the car. Or just substitute with a Vuo circle node.
You should be able to get by with just a Hold Value or Hold List node, don't need
Spin Off Event nodes in normal circumstances. The Hold node allows you to do the update on a value using its own contents in the calculation. Typically the update event going to the Hold node (allowing it to update itself) comes from a
Build List or
Fire Periodically node.
Will have a look at your comps when I get a chance. We're in the same boat I think :-)
I'm working with a similar constraint in my issues of understanding how to loop in Vuo ATM. Check out this simple comp I made to shuffle list values (attached). It includes a debugging method using the Console Window node and others. It allows you to see the events and values inside a loop, something show events or tooltips will not show you.
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
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 :-)