How do I get a simple 0/1 return value on mouse/trackpad click?
All of the options I seem to be able to find return the updated vec2 location of the cursor, not whether or not the mouse button is clicked down.
Also, it seems that even when no click/pressure/etc is happening, that some event from mouse type nodes pulses from the output. So it makes it hard (I think?) to get a clean interaction when that is hooked to something downstream.
I do have a composition this is coming up with, but I think it makes more sense to ask this first, because it is sufficiently complex enough that I want to make sure the mouse down is working before being able to understand the other parts are working correctly. Basically, I’m trying to get mouse down to trigger the Hold Value as well as switch Select Input.
One thing coming up with Select Input that is related to this specific situation, is that it used values 1 and 2 instead of typical programming 0 and 1, but it’s not the end of the world or anything…should be able to work with some math.
Has anyone put together a node or composition that has the vuo nodes for this outputting data that matches what QC would give?
edit: it looks like maybe Check Mouse Status may give some of the data needed.
edit 2: looks like I can’t get data events out of this node. When I press down on a trackpad, I can’t seem to get any event.
I’m also adding a picture of an editor glitch, where cable kind of leads to nowhere, but did seem to somehow be attached.
I have also seen a different editor glitch when editing this composition, where a port that has changed to display data conversion will have a greyed out “bubble” where the value had then displayed after a cable has been deleted.
The input port will start rendering correctly in the editor the next time the editor surface has been touched. This behavior is after app restart from the prior editor rendering glitch, so it wasn’t from the editor being in a corrupted state from the previous glitch. However…an app restart had this rendering correctly again.
So, thinking back on what I was doing, I believe this glitch was probably related to using undo in the editor, and then port reconfiguring not taking place correctly afterwards.
It is possible both rendering glitches were the result of undo, and subsequent editing that involved conversion of data from one patch to another, deleting of noodles, and/or attaching the output of newly created nodes to the input of nodes that had current connections.
I can consider filing separate bug reports for these, but just mentioning it now while I’m thinking about it. Â
mouse warp_glitch.vuo (6.88 KB)
Also, “Show Mouse Clicks” example composition does not seem to work properly on my system, using apple trackpad. Does it appear to work properly for others?
Trying the various click types seems to result in very inconsistent results; sometimes correct, sometimes aberrant wrong messages, sometimes ceasing to render any message even after the same user action.
You can use the “Receive Mouse Buttons” along with a “Select Latest (2)” to get a simple 0/1 return value (or any two different return values).
3 Likes
Hmm, looking forward to trying that.
I probably wouldn’t have found that in a million years. If it was in the example compositions (and I apologize for making the signal/noise ratio here worse if it was), I guess I just didn’t see it.
I can’t say I understand why that would work from looking at the graph in the picture but I look forward to it making sense to me!
I think there isn’t a system wide bool for the pressed status, especially with the force-press pads used now. The “Pressed” output fires one event when the pad/button is pressed, and the “Released” output fires one event when the button is released. The “Select Latest” then fires one event with the value from whatever input port got the latest event. Kind of a riff on an old trick when dealing with stubborn lighting console vendors that don’t want to implement different MIDI modes like toggle so that you’ll have to spend a couple $10k more on a console for a single button.
The wiring of what is what is arbitrary, and I could have made that part more clear (straight cables). The “Change Mouse Cursor” is also arbitrary, but is a quick way to check if the comp works with boolean values without involving layers or any other things. There is no event flow through this other than when a button/pad is pressed/released which is neat.
It appears that it’s still described in terms of mouse events, but as you state, there is an event for mouse down, and then a distinct event for mouse up.
I think one typical pattern would be for mouse down to toggle a value to true, and the mouse up to reset it.
Yet I suppose another usage pattern might be to not have a value toggle to true until mouse up occurs. So I am seeing why these nodes just expose the raw event, it does potentially give flexibility.
With that said, perhaps the composition you uploaded for me does the qc style “true” value when mouse button is held
down, and false when not…I haven’t had a chance to open it yet, but will shortly.
If not, I suppose that building a toggle object may be the solution. Â
@MartinusMagneson) how did you set the data types of Crosshair (Cursor) and Pointer (Cursor) on the select latest?
I can’t figure it out going through the list of More… data types,
note to @TeamVuo … I’ll FR this at some point I expect but just noting, it’s a shame you can’t just type C…r…o…s…s with the “More data types…” menu exposed and “Crosshair” is highlighted and hit return to make it so.
Also we can’t effectively use the keyboard arrows to preview all the choices quickly, unless you know where the item you are looking for is in all of the many sub-menus. We have to use the left and right and up and down arrows to navigate and it slow and pretty high cognitive load for something that needs to be super easy. Â
how did you set the data types of Crosshair (Cursor) and Pointer (Cursor) on the select latest?
Connect the “Select Latest” to the cursor input port, and the inputs of the select node will be set to the correct type. As long as a node is written to be generic, and the input makes sense for the application, this should happen. I assume the “Select…” group of nodes are among the few that support most (if not all) types.
1 Like
Sorry George, I deleted the image and file, didn’t realise it would kill on the site because they looked fine to me when I posted (must have been local browser caching).
You probably figured this out by now, but for those who come later and have a QC background, this is one of those tasks that is, in spite of it being a small task they’re a bit different in QC and Vuo just because of the lazy/non-lazy workflow. The closest QC patch to Vuo’s Select Latest node would be Sample and Hold I guess, my comparison is probably pointless. Better to think native VUO in this case.
mouse state in realtime.vuo (3.36 KB)
EDIT> LOL uploading the files again restored my previous post attachments Â
1 Like
I haven’t checked this stuff out again. I have to psyche myself up for it.
But while I’m thinking about it…I think the equivalent to Sample & Hold is Hold Value.
1 Like
Onother possibility :
Pressed Boolean.vuo (3.3 KB)
2 Likes
Yes, agreed @George_Toledo, Hold Value node is closer to QC’s Sample and Hold patch.
I wasn’t trying to suggest an equivalence b/w Select Latest and S&H in QC. just that there’s an event coming in, an update trigger if you like, and a value that might be independent of the trigger coming in, on a different cable if that makes sense. In this case the valse are received but permanent input values set up as True and False — the only possible input port default values once a Boolean data type output is set for the node. I’ve realised sometimes it’s not worth me making the QC analogy and this was one of those situations! Â
1 Like
