Yes, I got a track ball recently (for testing MIDIBuddy). I like it a lot and now seldom use the mouse. (After an hour or two of frustration). However I did find that it is more sensitive for certain things so not sure I would try to use it as a MIDI controller. It is actually a trackball mouse an I use my thumb to move the track ball. My thumb movements at times are a bit irratic.
All versions of MIDIBuddy have absolute movement. Just disable relative movement translators and you should be all set. I think the November 17 is likely the most stable build. If you don’t have it, I can send you the link.
In the translator, you could probably compare the change in X value and Y value and then only process the value that moves the most on output.
Hi Steve,
The thumb trackballs are not to my liking either. My fingers are much more deft and accurate for control. I think you could prove this to yourself by kind of propping up the thumb trackball and using your fingers instead of your thumb. Also, a larger ball gives you much more control.
I think I do have the Nov 17 version, I’ll let you know how I fare.
Thanks
Gabriel
Using absolute mode is now working for me. The trick to getting it to work for me is to use only one screen. I’ll explain below, but before I do that I’d like to ask if you could get MIDIBuddy to act as if there’s only one screen active. Otherwise, as I’m continuing to tweak my code, I can’t have Midi Translator on the second screen, which makes things pretty awkward.
Here’s the problem:
With two screens active, when moving in the Right/Left axis, the cursor (and the MIDIBuddy X screen position continues to increment as the cursor moves over to the second screen.
In order to get X and Y axis movement to match, I divide Y axis by 8 and I divide X axis by 16.
In my code, ga= X/16 if ga>126 then ga=127.
Now, the MIDIBuddy X axis count continues to increment though ga remains at 127.
X and Y axis movements match each other.
BUT there is a dead zone as the cursor continues onto the right screen and MB keeps incrementing the value of X.
Before ga begins to decrement again in response to movement to the left, the cursor needs to reappear on the left screen.
So there you have it. Is there any way to stop MB from continuing to increment once it reaches the right border of the first screen. I think most people working with two screens would want this type of action as well.
Hmm, since Bome MT only supports one screen as is actually sending out coordinates, this doesn’t make sense.
I set up MIDIBuddy for absolute movement so that it it tries to go off screen from the primary monitor. It stops sending screen movement messages.
Now here is the rub. If you actually move the mouse off screen, MT Pro will not react to any movements, since it doesn’t understand anything other than the primary screen (monitor)
I can check to see if this has changed but I don’t think it every tried to send commands when you go off screen from the primary monitor. This is NOT true with relative movement so make sure your relative movement translators are disabled.
Just checked and confirmed. Absolute stops moving if going off screen, however only if primary monitor is on left. It basically looks to see if either X or Y values are negative. However I don’t stop moving if it goes of to the right, so to get it working you should set up maximum screen position in your translator X and Y and ignore any messages from MIDIBuddy beyond your actual screen size.
I do set up a maximum X,. I’m going to simplify because I do an extra step of dividing MIDIBuddy X value by 16 so it matches the scaling of the Y value…. but put simply,
– as MB keeps incrementing X, I stop incrementing ga when it reaches 127.
– MB, though, keeps incrementing the value of X as it moves onto the second screen (on the right).
– As I move the cursor left again, ga doesn’t begin to decrement until the cursor reaches the right edge of the first screen.
– This causes a dead zone.
Maybe I could try swapping screen positions. I’ll see what happens then.
I don’t understand what’s happening. I’ve swapped screens, but now, as I move off the primary screen onto the left screen, I get the same kind of dead zone until my cursor reaches the left border of the primary screen.
Maybe I’m doing something strange in my MT code. Could you have a look and see if you have the same problem with Right/Left movement. I can’t attach anything to a comment, I think, so I’ll send my MT project in an Answer
BTW, I divide X value by 15 instead of 16. Otherwise I never reach the transposition value I need in the Pitch parameter of the SuperLooper. I’m sending a Live file as well so you can see what I’m seeing. As long as the cursor is in the primary screen, though, everything is wonderful.
I thought I had sent the files to you…. just being polite not to bug you, thinking you were probably busy.
In any case, the only problem I have with the 11/16 release of MIDIBuddy is that in absolute mode, Left Right movement of the trackball results in a deadzone when the cursor leaves the primary screen and goes onto the secondary screen.
I map left / right movement to Pitch in the SuperLooper effect in Live. In the Live file I sent, you’ll see the Super Looper at the bottom of the screen if you double click on the track name “FIVE” at the top left of the screen. Just for reference, when you click on the clip name “HOO MODULATED” you’ll see the waveform of the clip itself at the bottom of the screen instead of the Super Looper.
so…. When the cursor goes off the screen to the right (in my setup, the second screen is to the right of the primary one) pitch will have moved all the way to -12 st (steps). There is no further transposition as the cursor continues farther onto the secondary screen, and that’s ok, since the downward transposition is limited to -12 steps.
The problem is that when I move the cursor to the left again, I want the pitch to immediately begin to move back to -11, -10, etc etc steps. But this doesn’t begin until the cursor reaches the right edge of the primary screen again. Once that happens, the upward transposition starts again.
Is there a way to fix this?
In all other respects, MIDIBuddy achieves what I was after.
Thanks,
Gabriel
OK, the controllers on the MT Project don’t seem to match the Ableton file but I think I can figure it out.
The issue is that your actual screen size with 2 screens is greater than that of your first screen. I think the way to fix it is to limit the value of ga to the width of your primary monitor and the value of gb to the height of your primary monitor. That way when you go off to your second screen no more movement of the controllers, When you reverse the direction the movement will automatically start at the maximum value of your primary screen size and go from there so there should be no “gap”. Give it a try and tell me if this works for you. I assigned gx to the width of you screen and gy to the height. If you primary screen dimensions are different, you will need to reassign these values in the Init preset set global variables translator.
That doesn’t quite work. The problem is that the values of pp and qq keep incrementing despite the fact that we’re limiting ga to 1920. Therefore, once ga is greater than gx and then the direction of the cursor movement reverses (so that it travels toward the primary screen) there will be no decrementing of the final value of ga until it goes below 1920. The deadzone is still there.
I think you can see that even without Live running. Just watch the final value of ga as you move the cursor off screen, keep going, and then reverse the motion. That’s what makes me think that the only way to fix this is to fix it in MIDIBuddy, so that it doesn’t increment values after it reaches the limit of the primary screen. Is that possible to do?
I’ll look into it but it would be better if we could do it in Bome, even if we force the cursor position back to the maximum screen width. I think we could force a mouse move to 1920 by re-positioning the coordinate with MT Pro, however if we do that, then you would never be able to move to the secondary monitor with the mouse.
Even if we do it with MIDIBuddy, there would be a dead zone as I would simply stop monitoring mouse movements outside of the primary screen, so you would have to wait until the mouse returned to the primary monitor before it would start processing coordinates again. I think we need to figure a different solution. I think the key is, that you want it to keep processing coordinate location no matter which screen you are on. With scaling of 128 against 1920 that is quite a variance. If you have 2 monitors at 1920 then the scale would be 128 against 3840 which would make the scaling even more extreme.
I think you mean that I should divide ga by 30 instead of 15, but that leads to the same result… a deadzone once you go onto the secondary screen. I can’t think of another way to limit values in MT since the value fed to MT by MB keeps incrementing until you reach the limit of the secondary screen.
MIDIBuddy is just sending what it sees. I don’t want it to change that. We need to adjust the calculations in MT Pro to get th// e desired behavior. If you want to start decrementing the value while still off screen, then we need to consider the full range of the mouse and allow it to do the calculations, no matter where it is at. Maybe change the scaling and then remove the limits of ga that I added in recently completely.
Did you try that ?
Perhaps you should convert absolute values to relative values and then use relative values to send to Ableton.
Calculate the difference between the last X value and the new X value and send that to Ableton as a relative value.
I fear if you use two screen scaling, you will not be happy as you will need to move the mouse too much to move the knob.