I’ve encountered an issue that seems to have been discussed already in another topic (linked above), but it doesn’t look like it was resolved; or at least, I don’t see the solution explicitly explained in the topic.
I’m attempting to map MIDI messages to cursor movements; start moving the cursor left on a “Note On” message, stop moving the cursor left at the corresponding “Note Off” message, etc. I’m accomplishing this by activating a timer at the Note On message, and killing the timer at Note Off. The timer is activated with no initial delay, and repeats infinitely every 10ms. When the timer fires, it sends a Mouse Movement message with a Right/Left value of -50px. This is repeated for each cardinal direction.
The basic functionality seems to be working, as I can see the cursor moving around the screen with the corresponding input, but it doesn’t reach the edges of the screen. It’s like there’s an invisible boundary an inch or so inside each edge of the screen. I can move the cursor to the edges of the screen when using a normal mouse, and I can see the “Mouse Out” event is still firing at the bottom of the Bome window, but the cursor stops.
Similar to the linked topic above, my end goal is to use this to control looking/aiming in a video game, but in its current state, I can look around, but only in a very limited area.
As a proof of concept, I tried mapping a different note to move the mouse to the right by 150 pixels (no continuous movement with timers or anything, just move right 150px on “Note On”), and I see the same effect where repeated notes will gradually move the mouse right, but only to a particular point near the right edge of the screen, and no further.
I believe the issue is that if you are attempting to move the mouse right or left by 50 when that would overrun the screen width so , the mouse will not move.
I suggest the following solution.
Set up global variables for minimum, and maximum x and y values
// minimum x
ga=0
// maximum x
gb=1920
// minimum y
gc=0
// maximum y
gd=1080
// current mouse x
ge=0
// current mouse y
gf=0
Then in the movement rules, look whether you have hit the maximum or minimum and then if you have, adjust the mouse movements down accordingly
For Right movement
ge=ge+50
if ge>gb then ge=gb
Then use ge as the movement amount on the outgoing action of the timer instead of 50
//For Left movement
ge=ge-50
if ge<gb then ge=gb
etc.
Also I noticed that all of your translators you have defined the MIDI input device, it is better to do this at the preset level and then let the translators use the default port (controlled by the preset). This way you will not need to change a lot of translators if you later change your mind and use a different port.
I would also use note-off at “any velocity” as some controllers send note off at velocity of 7F.
EDIT: You may need to set the initial absolute mouse position in your project at project start as well so that your current mouse position variable match that of the current mouse position.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
I haven’t been able to actually try this out yet, but just so I understand the goal here, it sounds like the basic idea is to use global variables to keep track of the cursor’s current position and the bounds of the screen, and if we try to move the cursor beyond those bounds, set the cursor position equal to the bound instead of sending it past the bound.
Wouldn’t that just reinforce the issue that the cursor position is limited to a particular rectangle and won’t be able to move infinitely in all directions? Again, the end goal is to use this to control aiming/looking in a video game, ideally I’d be able to spin both directions indefinitely, so I don’t understand how this could be solved by explicitly limiting the cursor x/y coordinates to specific min/max values.
Yes, that is the thought. I’ve submitted a problem report to see if it can be fixed in Bome MIDI Translator or whether the fix has to occur in Windows. I’m not sure whether Bome is not sending addition movement messages, or whether Windows is blocking them. Of course if you steer offscreen, who knows what will happen? If you want it to wrap we could always send absolute mouse position to the other side of the screen if it wraps.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
I was able to use this idea to create something that’s functional, though it feels like a bit of a hack.
Like you mentioned, I initialized the globals to track the bounds of the screen and current cursor position, moving the mouse position by a certain amount at the timer, and if the desired cursor position is outside the bounds, it snaps to the other side.
I then increased the look sensitivity in-game such that one lap across the screen equates to one rotation of the player character. It took some tweaking to get the look sensitivity and game bounds to match up, but I’m now able to turn the character any direction indefinitely, with a barely noticeable ‘seam’ where the cursor reaches the edge of the screen and snaps around, which jitters the aim slightly.
I’m still curious to see if it’s possible to implement this without the odd strategy of snapping the cursor back and forth between the bounds, but for now this seems to be working pretty smoothly.
OK, thanks for the update! I’ll let you know if I hear anything back regarding the current standard methodology. Hopefully at some time in the future the workaround will no longer be needed.
I have a feeling to get this to work MT Pro will need to be “mouse aware” where it isn’t right now. Meanwhile I have written a helper program called MIDIBuddy (which is not a Bome Product) that works on Windows that sends mouse position and movement information to MT Pro to make it a bit easier. It however does send quite a bit of SysEx messages so if you turn on the log window, it gets quite busy.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz