Hi fellow Vuo-ers

Here's one I'm struggling with. I'm hoping for some advice on general patterns for designs flows where there is a large selection of things, and I want to filter to one thing, or output the first result that matches some criteria.

For example, here is my (nonworking) attempt to take a row of images, and detect a mouse click on one and highlight it.

So, I have a list of layers that I want to just find one (the first would do) and output that. However, the Process List node is optimised for doing the same flow to a complete list. In code, I'd just user Event Listeners, or a similar approach.

  1. How best to achieve my immediate goal of making a row of n images that are clickable (etc)?
  2. In general, is there an approach I should be using to find one-of-many? That is, to process a set of objects, with expectations of one (or maybe a short list) of results?

(Yes, yes, I know that Vuo is not a tool optimised for building UI. My problem still seems inside what one might hope to do with Vuo though, IMO.)

Comments

You could try something like

MartinusMagneson's picture
Submitted by

You could try something like this:

Looks a bit excessive, but should scale up pretty easily to 2d and 3d grids as well. The general idea is to select forwards, not backwards. That way you check the points and create and modify any layers/images/objects on those points based on an arbitrary input (mouse position in this case).

Once again, thank you

keithlang's picture
Submitted by

Once again, thank you Magneson for all your work in wiring this up. ๐Ÿ™๐Ÿ™๐Ÿ™

I gotta admit though, this makes me The knottiness of this solution makes me feel like Vuo is lacking something architectural. I know all nodal stuff can end up a bit like this, but this just feels like there is some fundamental piece missing to avoid this knitting. ๐Ÿ™‚

Thanks again for your help!

keithlang's picture
Submitted by

Thanks again for your help! So I think I found a nice solution, for me. Spin Off Events is rather handy (feature request: Spin Off ValueS) for this task.

Although, looking over it, it feels like we have very similar solutions in some ways. ๐Ÿ™‡๐Ÿปโ€โ™‚๏ธ

This comp takes an a group of layers, and overlays a rectangle that matches the layer pos+size, if mouse is over it. only works for non-overlapping rectangles, which is my use-case.

For some reason I couldn't get Is Point Within Layer to work. Could be user error, but could be buggy?

Haha, it was way to late in

MartinusMagneson's picture
Submitted by

Haha, it was way to late in the evening when writing that, and I didn't exactly do a good job of explaining! Good to see you got it working! One cool (or annoying) thing with your approach is that it should be fairly easy to animate the overlay using the Smooth with *** nodes so that it glides to the next one instead of popping over. A thing to keep in mind when using Build/Process List is that the whole function of the loop has to be contained within that node hierarchy, or you'll get errors. This means that you can't pass a value from inside the loop to an outside node without it being part of the "Finished Building" port. I suspect the issue might lie there in your first iteration.

To explain my approach a bit better (hopefully), system nodes are lime, math nodes are yellow, input is blue, constructors are magenta and the build loop is orange. In addition the hold nodes are there to sync outside values to the loop and are colored violet.

It works by first getting the window dimensions and setting the start/end of a "Points along Line (2D)" to the left/right points of the window. The width is then divided by the amount of elements you want, that gives you the per-layer dimensions, and also a "bounding box" for checking the mouse position. Height is hard-coded to 1 in this instance, but the height calculation is the same as for width if you want a 2D grid (or 3D, but then you'll need depth and a different input than the mouse to get a 3D point to check).

This data is then fed into a "Build List" node that checks the mouse position and then create the layers based on that input (changes color if the point is within the rectangle bounds of the point). This way you set up, create and check all parameters before making the layers, what I clumsily referred to as "selecting forwards". This as opposed to creating the layers and doing the selection and manipulation after the fact (or selecting backwards).

For me the flexibility that points provide usually is a lot easier to relate to, but as it is more of an abstract way of thinking about compositing it can be a bit of a task to wrap your head around it. In that vein, the composition I posted isn't restricted to layers, but can be images or objects, or even points to generate other points from (which can again be used to tile layers/objects/images/points. To swap it around, the only node you need to change is the "Make Rectangle Layer". To organize things in a circle, swap out the "Make Points Along Line", insert a MM.Spirograph node (for simplicity) and add the calculations for height.

I do think that the learning curve might be a bit steep, and see the need for simple UI nodes. I also understand that it's hard to make a one-size-fits-all node for these things without it being an unwieldy and huge node to account for all permutations of how to select things. Most of it should by now be possible to do with subcomps, which I think is the preferred way of solving it as they can easily be changed by the end user.

For me, I much prefer the

keithlang's picture
Submitted by

For me, I much prefer the more structured way of working, where there can be a list of images, and each image can have its properties. I can easily move this group of images through a flow, and if I need to get the property of an image, then I can. If anything, I wish I could work more like this.

There are some other issues I see making this harder than I'd hope for. One is the requirement to supply Window detail to a patch. 1. Wiring across large distances (often requiring scrolling) is actually quite physically difficult. And cognitively difficult to keep track off, even when the wire is hidden. 2. The need to wire stuff from the end of the composition back to the beginning is annoying and messy. This applies to anything mouse-y. I wonder if we might guess that 90%+ of compositions only ever have one window. If you want mouse coordinates relative to the window (which I would guess is vastly most common scenario), then you need to wire from the far ends of your composition.

There's no user hack I can think of that could make this easier.