Mouse movement jumping by 100s of pixels

I’ve tried both midi encoders and buttons to test out outgoing mouse movement. no matter how many pixels I assign to mouse movement (from 1 to 10) it results in the mouse cursor jumping by 100s of pixels.

if I assign the same variable to move the mouse via “outgoing mouse position” it moves smoothly, applying the CC value to the Y coordinate, for example.

is there something I’m missing when assigning the CC value variable to outgoing mouse movement?

If you can post your latest project file, I can have a look. Is it possible that your encoder sends relative values like 127 for negative 1 and 1 for positive 1? Many relative encoders do this in which case you need to use rules to calculate the movement.

For the instance above, the below rules would work

Incoming CC 1 on MIDI channel 1 any value set to qq

if qq>0x40 then tt=128-qq
if qq>0x40 then tt=tt*-1
if qq<0x40 then tt=qq
// optional if it doesnt move enough
tt=tt*3

Outgoing: Mouse movement Y Coordinate amount tt

Steve Caldwell
Bome Customer Care


Also available for paid consulting services: bome@sniz.biz

The encoder I’m using is absolute, sending CC values from 0-127 according the Bome’s MIDI capture.

The same occurs when I trigger the mouse movement with a CC button.

Attached is the project file that demonstrates this with the CC button.

The Log Window indicates outgoing “Mouse move 10 (down)”. But the cursor moves a much longer distance up instead. Cursor actually goes up despite setting mouse movement -/+ in right/left or down/up.

CC Button to Mouse Moevement 10 Down.bmtp (999 Bytes)

Hmm it is working fine on my system. Are you on Windows or Mac? Do you have any special mouse drivers or macro programs running that might affect the mouse movement?

Demo Video

Steve Caldwell
Bome Customer Care


Also available for paid consulting services: bome@sniz.biz

Very strange. I’m running Windows and I don’t have any special mouse drivers or any macro programs affecting mouse movement.

If I use mouse position instead of mouse movement, then the movement is smooth like your screen capture.

Hi @ochaim, thank you for the report and sorry to hear about this problem.
The relative mouse movement works like this internally:

  1. get current mouse position
  2. apply offset (x and y values)
  3. set new mouse position

Now unfortunately, the Windows ways to get and to set the mouse position are very different, so MIDI Translator Pro has to do some calculations in between steps 1 and 2, and in between 2 and 3. We need to consider the number of monitors, their arrangement, and in particular the scaling for each monitor.
(given that absolute positioning works, I assume that step 1 or the calculation in between 1 and 2 fails).

Could you please post your monitor arrangement and the resolution and scaling for each one? You can find all that in the Windows Display settings.

Thanks!

I have 4 monitors in a 2x2 configuration, Their resolutions are:

1600x900 | 2560x1440
1920x1080 | 1920x1080

Scaling is 100% for all 4.

Thank you, that’s very useful to know. We’ll work on this and report back here.

Maybe you can work around the problem by keeping global variables for x and y position, and then use absolute positioning when you want to move the mouse?

I think I found the culprit to be a HDMI to DisplayPort adapter I’m using. This incorrect mouse movement behaviour only occurs when it is used. When this monitor is connected directly via HDMI, the mouse movement is fine.

Do you have an example of how to execute the workaround you described?

wow, that’s an unexpected problem! I have a couple of adapters like that here, too and will experiment.

@SteveC do you know what I mean and could take over? Thanks!

@FlorianBome
Yes, chime in with something when I get up tomorrow morning . Pretty much out of pocket today. Sorry!

Here is my example of a work around.

When the project is opened or the computer ESC key is pressed, the mouse will go to the center of the primary display and set the global variables ga (x-position) and gb (y-position) accordingly.

Here are the global variables used in the project. In this example I’m only using the primary display

// Screen 1 X coordinate
ga=0
// Screent 1 Y Coordinate
gb=0
// Screen 1 X Resolution
gc=1920
// Screen 1 Y Resolution
gd=1080

I have Note 0 to move up 10 pixels Note 1 to move down 10 pixels, note 2 to move left 10 pixels and note 3 to move right 10 pixels.

I set the pixel movement amount in the rules of each translator.

Here are the rules for up

gb=gb-10
if gb<0 then gb=0

The outgoing action is then to set the absolute position on screen 1 as callulated in the translator rules.

Note, if you move the physical mouse, then there is no way to calculate it’s true position so the new position will be based on it’s “remembered” position and no longer the true position of the mouse.

I f you are on Windows I have a separate helper program “MIDIBuddy” than captures the real mouse position and sends MIDI to MT Pro so that the true position of the mouse can be maintained. MIDIBuddy was written by me not Bome Software.
It is primarily a workaround to detect the true mouse position on a Windows PC by Bome MIDI Translator Pro.

Here is the example project file.

Mouse-Pos-2021-06-27.bmtp (2.3 KB)

Steve Caldwell
Bome Customer Care


Also available for paid consulting services: bome@sniz.biz