hello friends

i have a hard time processing the data received by a mouse, maybe you can help me? I understand from the hid help file the mousedata is relative. So it should give us the amount of units it has moved since the last value was returned in axe X&Y.

so basically when the mouse stopped moving, in my understanding this value should be 0 or it shouldn't bang information at all. but when i connect an usb-mouse or use my internal trackpad, it keeps banging the last received input before i stopped moving the mouse. this is mostly a 1 or -1, but not always. it can be any value.

do you guys got an idea to filter this datanoise away? my first thought was to install a sort a counter connected to a gate so after an amount of the same values, the gate would block the received data. but this would basically say you can't move in a constant speed, or otherwhise the data would be zero.

or do i maybe interpret the data completely wrong ?
thanks a lot

Not 100% sure what you're after, are you using [hid/mouse 1]?
Have you tried putting a [change] on the X and Y outputs? That will filter the repeated values/bangs when the mouse is at rest.

hi lead

jes, i'm using [hid] connected to an external mechanical mouse.
[change] would indeed filter out the repeated values.
but when moving the mouse in a continuous speed,
the X and Y outputs would be a stream of repeated
values too, so [change] would filter those values out
also. and i don't want that

btw:
here is a video of the project i'm currently working on.
the strings are attached to the X and Y axis of a mechanical mice.

here i worked with [cyclone/MouseState] (the right arm, but the range
was too small) and with [hid]'s raw data (the left arm, because i didn't
know how to process it).

Looks like a cool project.

Attached should be a patch I made with a trackpad.

The problem seems to be that you need to poll the mouse to find out if it's changed or stayed the same, which results in the repeated values.

This uses any movement on either axis to check/output both, which isn't perfect but might nearer what you're looking for.

There's also a sort of activity-gate made with [vline~] that might be useful.

http://www.pdpatchrepo.info/hurleur/Mouseges.pd

vandijckv,

I'm currently trying to solve this exact same problem for my own purposes. Not solved it yet, but here are a few ideas that might help:

• when the mouse is stopped, it's usually a small number that repeats (less than about ten or so, in my case). When a value repeats because the mouse is moving at a constant rate, it will probably be quite a bit higher than this. Could use a [moses] to distinguish between the two.

• when a value repeats a lot of times in a row (say, more than 10 or 15), then it's highly likely that the mouse has stopped moving. You could count the number of repeated values and set the output to zero after a certain number of them have passed (or a certain number of miliseconds). Disadvantage of this is that in entails a delay, but at least you can reduce that with a high polling rate.

• when the mouse is moving normally, the data stream seems to come unevenly... If you attach a [timer] to the stream, you'll find that the data comes at the polling rate, but occasionally two bits of data come at the same logical time, with 0 miliseconds between them. This doesn't happen when the mouse is stationary, so you could conceivably use this to distinguish between the two cases, although this doesn't seem that robust.

The second option seems the most reliable of the three, but the delay it entails is a drawback. It might be best to use a combination of two of them, somehow - I think I'm going to investigate combining the first two methods and seeing how that works. Will post back here with anything interesting.

thanks a lot lead and stutter,

• lead: great patch. had something similar, but more complex. still a newbie in pd . but the patch doesn't solve the problem when the mouse is moving in a continuous speed.

• stutter: nice to know that i'm not the only one trying to solve this puzzle. you got some good ideas. will try to implement them in my patch too. looking forward to any breakthroughs.

How about setting a lower limit to the output?

Something like

[hid]
|
[t f f]
| |
| [> 5] (for example)
| /

• The tradeoff is that you'll lose a little precision, but hopefully you'll be able to find a value for the threshold that's low enough that you don't feel it, but high enough that it will block out the noise.

Oh, and be sure to stick a [abs] before the [> ].

Vandijckv,

Here's my best attempt at a solution. It feels somewhat hacky, relying as it does on a weird quirk of the message timings that could be specific to this version of [hid], or to my operating system, or whatever - but for me it was actually the most reliable and robust of all the methods I tried.

If you look at the attached patch you'll see that all of the interesting processing goes on inside the detect_motion subpatch - which, as I mentioned, checks the timing between messages to determine if the mouse is moving or not. It seems that when the mouse is in motion, the messages come in 'bursts' - that is, groups of two or more messages arrive at each polling interval. When bursts such as this come, the messages are all passed without changes. When two or more intervals pass with only one message in each (i.e., no bursts), the mouse is considered to be stationary, and zeros are passed instead.

This seems to work fine for me, although if you wanted to be really sure of not missing any motion at the risk of picking up a few erroneous extra messages, you might want to try increasing the number of intervals to wait before deciding the mouse isn't moving, by increasing the 2 in [moses 2] to perhaps 3, 4 or 5.

One other thought - since the messages arrive in 'bursts' of a few messages without any gaps between them, it may be that all except the last of the messages is effectively getting ignored (depending on how you use them). It might be worth building a little something to 'sum' the numbers in each bursts - but that's a job for another subpatch.

Hope that helps! Let me know if you need any help figuring out or adapting my patch.

http://www.pdpatchrepo.info/hurleur/mouse_detect_motion.pd

Well, I made it for myself anyway, so I might as well upload it: here's an updated version of the above that does the summing thing I mentioned also.

http://www.pdpatchrepo.info/hurleur/mouse_detect_motion.pd

hallo stutter

thanks for your response. at first sight the patch doesn't work on my system. now i'm trying to figure out what's going on inside detect_motion and checking your theory of the information bursts. i wondered if you could help me with some questions about it.

[timer] detects the amount of time between the incoming messages. so normally when doing nothing, the messages are received at the polling rate (in this case being 25). when moving with the mouse i detected that this number increased sometimes, but not always, in a range of 50 - 200. is this what you ment with the bursts of messages? shouldn't it then always increase when moving the mouse instead of increasing sometimes?

what i also don't understand is that there is this [moses 1] after [timer], because isn't the output of timer always > 1?

shouldn't it be
[timer]
|
[== 25]
|

• |
  [moses 1]
  |
  etc... or something like that ?

Hey vandijckv!

That sounds like bad news - I suspect it is not possible to get my patch to help you. I guess that the hack does rely, as I suspected, on a weird quirk of my operating system! What operating system are you using, by the way? I'm on Ubuntu Linux.

The [moses 1] is because, on my system, the intervals [timer] reports are either 25 or 0. (I guess the fact that it outputs exactly zero rather than just a very small number is because it measures 'logical time' instead of real time?) It sounds like this is not the case for your system, so I think my patch won't be any good to you.

However, I suppose It's possible you might be able to come up with a similar fix for yourself based on the increased timing you observed when moving the mouse.

hi stutter

that's a pity. it's cool that you found out about that weird quirk. suppose i will find something else to get around it . i'm using mac os x.

a ha, that explains the [moses 1]! really strange that different operating systems are reacting differently.

thanks anyway for the effort, stutter
really appreciated it!

Yeah, it's a shame. I suggest the best method for you may be to look at how many times each value repeats, and block them if they repeat more than, say, 5 or 10 times. I think that should be fairly accurate - maybe the best you'll get. Good luck!

I know this is an old post, but... anybody found a solution for this?
I have the same problem with the repeated bangs using relative mouse position and hid.

Hi.
Thanks to the Stutter suggests and to Gilberto, who on another post explained me how use expressions, I have made a little patch for work with hid using relative mouse position avoiding the repeated bangs. At least it works with my optical mouse.
Well, is not the best solution (it doesn't works right if you move the mouse veeery slowly) but at least it works.
Of course my knowledges about pd are minimal, so sure it can be done better and someone could improve it.
Also I don't know if someone has already given a solution before, in case, I leave the patch here.
Hopefully helps someone.
rel_mouse_hid.pd

Thanks guys for solving this! I was struggling with the same issue. Every poll hid would send out two different values for a stationary mouse.

Thanks jjbarrows, I also worked on another "better" or at least more precise solution for this problem here.
But is more convoluted and requires two simple linux (maybe also for osx) external programs.

Thank you soooo much for this work. Just saved me hours!!