Measuring speed of motion across an XY-pad
Hello, sorry if this is a stupid question or a really obvious answer, I'm a complete beginner and I've tried googling this and checking the reference guide but can't find what I'm looking for.
I have a simple XY-pad set up. I would like to know not just the position of the cursor but the speed at which it moves across the pad.
I figure the best way to do this would be to compare the cursor's current position to its position an arbitrary amount of time ago (say 10ms) which would tell me how far it's travelled in that time and therefore act as a proxy for its speed.
Unfortunately I have no idea how to take the input of an integer at a consistent rate, since every time the number changes it outputs a bang.
I hope I've explained myself clearly enough. If anyone has any idea how I could achieve this, or thinks my plan is stupid and can show me a considerably easier way to get the information I want, I would be very grateful.
Thanks.
Sorry, I think I could be more clear about what I'm trying to do.
I want to store the cursor's position (say for 10ms) and then take it away from the cursor's current position, giving me the distance travelled in that time, which I can use as a proxy for the cursor's speed.
I don't know how to store a number at a regular interval without it being updated every time that number changes.
Hi, I don't know how to delete a post but I've worked it out - I needed to use two zl.reg objects attached to a metro (one with a delay).
You're on the right track.
You don't necessarily need to have a metronome, you can just compare previous position with the current one:
But if you want a time based speed, you can use a [metro] to get bangs at regular interval.
Unfortunately I have no idea how to take the input of an integer at a consistent rate, since every time the number changes it outputs a bang
I think you're missing the concept of hot and cold inlets. Hot inlets are the red inlets, and are usually the leftmost inlet. Cold inlets are blue and usually the other inlets. When an object receives a message in a hot inlet, it triggers an output from one of its outlets, which is not the case wen it receives a message from a cold inlet. So if you want a constantly changing value to be output only when you want, you can store it in an object ([message], [int], [float], [zl.reg]...) using its cold inlet, and bang its hot inlet to output the current value when you want.
Like so:
EDIT: You answered yourself before I sent my answer, I didn't saw your other posts, so sorry if I felt pedantic!
for time based you could also measure the time between coordinate changes instead of using a permanent clock.
Interesting Roman! Might give various results depending on the input object. [nodes] indeed seems to send more messages when moving faster, but is it the case for all Max UI objects?
Actually thinking about it, it doesn't make much sense to me: why does a slow but consistent movement should result in less frequently updated position than a faster movement? I understand it would be the case with low reslution XY pad such as a 127 values MIDI thingy, but in float32?
if something is coming from mouse movement and you want to measure something velocity or speed about it, it seems obvious to use [timer] and not have a metro or o ther clock running.
it will be more precise even, and it only cause messages in overdrive when needed. but otoh it might become more difficult to implement things like init and restart. which is why i have no idea to provide an example.
your patch above should be a good start for this, as it has everything else already. using elapsed time between events to multiply the "time" value in this patch will give you the respective realtime values.
Ah it makes sense when you explain it but I can't manage to get consistent result. It gives a very jittery output and even after smoothing is feels less accurate than the position based method. Also, I assume it might give very different results depending on your screen pixel density.
The main advantage I can see of using a clock is that the speed goes back to zero as soon as you stop moving, not only when you release the click (at least in this setup). But for sure it might require more cpu resource.