Magneson (@MartinusMagneson)
Compositions
The reason for this is that while the build list outputs an index number (which you use to name the object), the process list outputs a layer. So where build item will give you a number 1 - > ∞, process item will give you the layer info as a value. That means that after converting to a summary, instead of getting a text "1" ... "∞", you'll get a text "object named "1", ...". Since you don't have any layers named "object named..." it won't register any true conditions for any present layer.
There are multiple ways to solve this. The simplest perhaps is to put all of the functionality into the build list.
A different approach would be to generate lists for position and size, generate one oval layer, and do the size/movement with a copy layer node (perhaps a bit more efficient?).
Note that the movement change feedbacks its position making it glitch if the mouse is in an in-between old/new position as the moved layer has new bounds which would again move it outside the mouse area, moving it back to its false position, resizing it because of mouse position, move it outside the area and so on. This won't happen if the new position covers the old area as well (only moving it by the offset the new size generates).
The short answer is that it fits in anywhere! Which is the beauty of it. If you think linearly, this very simplified diagram might help, but maybe not really.
Since you basically can adjust things before or after the fact, it depends a bit on workflow, and what you want to achieve. If you follow the diagram, an image is an end point of the comp. But it can also be the beginning if you want to shade with an image. Or both if you want a feedback-y kind of shader for your comp.
I played around with a simple composition the other day that perhaps can demonstrate the flexibility and intertwinedness(?) a bit when it comes to where you should be putting values and things (boxFlip.vuo). It is how I view it though, there might be better ways to do it. The comp creates a cube (object), copies it and applies a transform to the position (points). The same points are used to sample a color (well, color) from an image input (or in this case live video from the cam), and use the lightness value (real(point)) to create a list of rotational values for the transforms (point). It is then rendering the scene to an image which goes to the output.
The cube is created at the beginning, and then copied since it is an array of similar objects, and it wouldn't be as efficient to create 625 meshes when there already is an object to copy.
There is no "Hold" node before the "Get Item from List" node going from the point grid because it gets generated at the start and it isn't animated (no events after the first). If the grid was animated, a "Hold" node would be required, or at least an "Allow Changes" node for intermittent adjustments to prevent stuttering and glitches (due to the two data streams being out of sync).
To run the composition, you'll need to put the Magneson.Points.2dGrid.vuonode in your user modules folder (WIP warning, should work, can't guarantee it).
If you haven't already, check out my nodes (and all the others!) in the Node Gallery! They are a bit all over the place at the moment, but should provide some useful tools for a lot of different (perhaps niche) stuff. Especially when it comes to lists.