Sorry if this has already been answered in a general sense somewhere else but I didn’t find anything.
I have a simple set of nodes that splits a list of 2D points into individual data points and passes each one through it’s own Smooth with Inertia node. Then recombines each data point into a 2D Point list the same length as the one that came in.
Feeding it unit test data in the same composition it works fine, and I’m using it in another much larger composition. But as soon as I make it a sub-composition and feed the unit test data into the sub-comp node it outputs a list of null data (same number of 2D Point elements but all (0, 0) in value).
One thing making this made me realise, when you make a sub composition for smoothing you necessarily don’t want to have to commit the data-type of the nodes within it.
Keeping it generic would allow it to be used for as many datatype as the Smooth with Inertia patch can accept. But it’s not possible to make the sub comp without hardwiring a datatype into the composition, in this case 2D point. If possible it would be ideal if the sub composition could accept a list of n–dimensional points or colours etc. I’m not sure if a future Vuo could do that?
Thanks Jaymie, I had noticed that thread but didn’t realise that’s the exact same problem with this sub composition. Is it fixable if I work out how to filter the events or do I need to wait for 1.3 to do this?
Yes, here’s a fix. I was going to propose inserting an Allow Changes node into your subcomposition, between the Data published input and the node labeled Data, but that node doesn’t work on lists yet. So instead I added another published input to the subcomposition to detect changes.
Thank you Jaymie, I’m trying to get it running in the test rig composition you made. When I opened the “useful design.smoothListWithInertia 20170904.vuo” file and then use File>Move Composition to Node Library to put it in the library, the name of the Node becomes (of course) “Smooth List With Inertia 20170904” so I have two nodes, I guess I’m supposed to replace the old one? Also weirdly the file name now becomes usefuldesign.usefuldesign.smoothList…. I wonder if there can be an easier way to depreciate old versions of nodes than this.
Opening the test rig file you made it seems to be using the old node, even though it doesn’t have the new input port “Which Data”. I’m going to try replacing the old Node with the new version you’ve made. Perhaps we need a Menu item called “Replace Existing Node in Library with this Composition” to streamline this kind of operation?
Okay, I got it working thanks @jstrecker using your modification and replacing the old Smooth List with Inertia node with your one. But your test rig composition file didn’t work as is. Trying to figure out why exactly.
I had to delete the old Smooth List node and drag a new instance in from the Node Library and rewire it. (Attached (6.27 KB)) I wonder what went wrong with the test rig file you made, or maybe you just uploaded an uncompleted version? I’m new to sub-compositions so not sure what the ideal work flow is yet, but i think something has gone awry here and keen to understand why it wasn’t a case of just dropping in the new Node to my User Module folder and renaming it to replace old one and opening your test rig file.
Ideally we should be able to even do it all from the Vuo application, i.e. open the new node file and go File Menu> Replace An Existing Node with this Composition…" and open the test rig file and it’s all working as it was for the other user who made the modifications. I guess that menu item would present you with the Node Library list and filter to choose what node you want to replace, or if no filter is possible in the modal dialogue, maybe highlighting the last node that was selected in the Node Library.
Getting back to the sub-composition itself, sorry for being a bit remedial, but why do we need this particular workaround? (I’ve gone back and read the thread you linked to, @jstrecker, about sub-composition input port behavior but it’s still not clear to me how exactly that was the problem here).
If all incoming event triggers are passed to all sub-comp input ports, shouldn’t the constant updating of the Time input be enough to prompt re-evaluation? I don’t understand why the Data list needs a Hold node (as if it was in an iterator loop) and refresh event when the data changes.
I don’t understand how the Allow Events node would have helped if it did work with lists. In fact I can’t see what it does in any context, surely any wire carrying a value that changes will reflect changes to the data, can data change without passing through the event that caused it to change?! Maybe I’m missing something fundamental about Vuo, so I’m going to ask this question about that node separately.
The problem was that every event that went into the subcomposition would go through your “Data” node through Take from List and hit the Set Target input port of Smooth with Inertia. The Target port is supposed to get an event only when you want to change the target, not every frame. The purpose of the nodes I inserted between the Data published port and the “Data” node was to block all events to “Data” except when the target is supposed to change.
Thanks for explaining Jamie, I had an hour long riding home last night and I got to thinking that must have been it otherwise why would you be watching for a change in the data? :-)
Firing events each 0.2s into the Smooth demo comp confirms they go funny. Especially Smooth with Rate which is more time dependent (in shorthand) for it’s movement function.
Right, because each time Set Target gets an event, the node recalculates its plan for how to get from the current position to the target. Good demonstration.
