This works as far as Right / Left motion. However, I abandoned the Relative Mode solutions a while back since motion Up / Down has the unfortunate effect of sporadically increasing and decreasing the Right / Left amount even if I want R / L to stay the same. I can almost make up for this by moving the mouse diagonally up and left when I want to increase Up / Down value. This has the effect of making sure that there is never an increment in R / L (because I’m consciously decrementing R / L. But this only works if I’m trying to keep R / L at value zero. Otherwise, say at R / L value 40, it’s not really possible to keep U / D from fooling around with the R / L value.
All this is somewhat better with a mouse, but with the trackball, the geometry of the rotating ball makes it impossible to control.
Well that is the only way I can think if getting rid of the dead zone. But now it may be different by having Bome converting the relative movements. What happens if you use Bome to convert both X and Y movement to relative?
May end up being the nature of the trackball. On my trackball mouse I have a setting with SetPoint to alter the direction slightly of the ball itself because the ball sits to the left of the mouse. Of course SetPoint interferes with some of the button elements in MIDIBuddy.
In order to control the dead zone in Left/Right movement of the trackball, I’ve found two solutions.
When doing programming related to MIDIBuddy, I just watch the cursor, and visually make sure I don’t move it onto the secondary screen.
Since this is unwieldy during actual playing, and since I don’t need the second screen while playing, I just change the NVIDIA settings to single screen.
Nothing else seemed to work, and this works well enough for me.
One small bug to report. I notice that after a variable time of working with the trackball and also editing the MT code, the space bar no longer produces spaces in the text. It’s as if the space bar is broken, but all other keys seem to work (actually I haven’t checked them all, but I think they do).
What do you think is going on? It’s a bit disconcerting, though, so far, I haven’t found it to impact anything other than keyboard text entry, which I don’t do during playing. It does get in the way of editing my code, though.
Hi Steve,
It’s absolutely replicable. MIDIBuddy is off now.
Launching MIDIBuddy now:
MIDIBuddyislaunchednow.I’mhittingspacebarbetweenwords.ExitingMIDIBuddynow:
MIDIBuddy is off now.
Is there some setting that’s different on my computer from the setting on yours? I don’t recall this happening before. This is with 11/16 release. I’ll try reinstalling.
By the way, was there ever a version that had unique Absolute mouse movements (as there are for Relative movements?) Since I’m always using the Absolute movements now, unique would be very useful for me.
Gabrfiel
What is your Magic key configured in “settings”. Try deleting your MIDIBuddy.ini file when re-installing it which will require you to also configure your MIDIBuddy output port.
It happens regardless of whether or not I’m running Bome MIDI Translator. I can boot computer, go directly to notepad, for example, then launch MIDIBuddy. Then, when I type, spacebar isn’t working.
I’ll now try reinstalling MB and deleting the ini file.
No, unique mouse movements are always relative movements. It takes the raw input from the mouse. Absolute movements are the mouses reported position on the screen from Windows.
Glad to see that deleting the INI file did the trick. My guess is somewhere along the line it showed the special key as a black (space) so your INI file somehow got corrupted. Not sure how that could happen unless you manually edited it.
OK… I understand.
I think maybe there’s a way to differentiate the trackball from the mouse, or one mouse from another. I could lookl at the input in Bome Midi Translator, on the basis of which mouse is being reported as active by the relative routines, decide what to do with mouse movements from one or from the other of my mice.