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

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!!