MIDIBuddy - Adjustments to range of action

Bome Products
1

Hi Steve,

The new approach of scaling the range of MIDIBuddy action by adjusting the range of the screen area in which MIDIBuddy "notices" mouse movements isn't working for me. Here's the problem, presented as clearly as I can state it:

  1. Adjust left border of active area this way..... tt=kr/3 , for example.
  2. Move mouse left so that it approaches the left border of the active (adjusted) area
  3. During this movement, the X-Axis output correctly decrements (toward value 0)
  4. Once left border is reached, the output correctly reaches 0.
  5. Now continue moving mouse left. The output correctly remains at 0.
  6. During this movement, though the output remains at 0, the feedback to BMT from MIDIBuddy continues to change in response to the continued mouse movement. This is as expected but may be the reason for the problems below.
  7. Now move the mouse to the right. This should result in immediate incrementing of the output value.
  8. What happens instead is that the value remains at 0 until the mouse position reaches the adjusted border.
  9. Once the border has been reached, the output value starts to increment correctly.

So, I think the approach of adjusting the screen area in which MIDIBuddy is responsive to mouse movements doesn't work, for me, at least. The dead zones outside the active screen area are a killer for me.

I will say, though, that somehow, this last fix has actually fixed the problem of over-running the left and right limits when I move the mouse quickly. I can always achieve 0 and 127 now, no matter how quickly I move the mouse.

Is there some way to prevent the dead zones that occur when going outside the active screen area as defined by MIDIBuddy?

2

Hi Gabriel,

Yes the behavior is how I designed it, I think what you are looking for is to use the full screen but have a greater sensitivity and never go over. Is that correct?

 

If you set the scaling to screen size instead of “active area” as I have it. You can just adjust sensitivity. I’ll come back in a bit and drop in that solution. Let me know if that is what you want to achieve.

Here is the behavior explained.

Moving mouse left from any position on the screen decrements the output CC value from MT Pro if not already 0.

Moving mouse right from any position on the screen increments value if not already 127.

Reversing the direction immediately increments or decrements upon reversal (no dead zone)

Sensitivity can be adjusted.

Right now it is set for this behavior

Increment value if 1/3 screen to 2/3 screen 1/3 is 0 2/3 = 127.

Moving mouse outside of this area has no effect remains at zero if left of 1/3 and remains at 127 if right of 2/3

Steve

bome@sniz.biz

Independent Bome Programming Specialist

Bome Q&A moderator

 

 

3

Hi Steve,

The action you propose is just the way I’d like it to be. I’ll let you know after you post the project file.

Thanks,

Gabriel

4

Try this version. The issue is that since the range of a controller (127) is so much less than that of the width of your screen (1980). You have to move at least 15 pixels for the controller value to change if I use standard scaling.

So if you move your mouse in small increments <15 pixel then the controller value does not change. The translator will only see movements of more than 15 pixels. If you move 14 pixels on the first iteration and and another 14 on the next iteration, they are not additive. We would have to set up a global variable to track cumulative pixel movement so that it is persistent between iterations. I have to explore this further.

In the meantime, I just set the sensitivity hard coded to 3 pixels. Give it a try and see if it floats your boat. 😉

If it is to sensitive, we I will need to set up more global variable. The first to indicate direction so I can detect direction reversals. The other to indicate cumulative movements of the mouse until direction reverses.

 


Attachments:
1509050065822_Gabriels-MB-Code-2017-26-c.bmtp
5

Hi Gabriel,

You might find this more to your liking. As I indicated, I added a global reversal variable and a cumulative counter.

I also added cases for special conditions so that you you go off screen on the left, the value gets set to 0 and if you go off screen to the right, the value goes to 127.

Also when you reverse direction , it will immediate move the value because on reversal I set the cumulative value to the value of the scaling factor.


Attachments:
1509052207319_Gabriels-MB-Code-2017-26-d.bmtp
6

Steve!!!! MY MAN!!!!

You got it just right in this version. I think even the sensitivity is perfect in relation to my trackball, at least in the X-Axis. I’m so pleased.

Could I ask you to create a new Y-Axis translator as well? There’s a lot more to the algorithm this time than last, and I have a feeling I’ll struggle with it….though I’ll give it a try tonight.

And one last thing. I will be directing the output value to several different effects in Live…not at the same time, but when I bring in Beat Repeat by sending it a MIDI command to turn on, then the output of MB will be directed to the parameters in Beat Repeat. Similarly, when I invoke the Ping-Pong Delay, I’ll then direct the output of MB to that Delay.

The problem with using absolute values in this scenario is that when I switch from one MB destination to another, there could be a big jump in the parameters. What would happen is this:

  1. Engage Beat Repeat.
  2. Move Trackball so that it reaches maximum x and maximum y value
  3. Engage Ping-Pong Delay (thereby losing link between MB outputs and Beat Repeat
  4. Now Move trackball.
  5. Since the Ping-Pong Delay may have been left with minimum x and y values the last time it was used, there would be a sudden jump from minimum values (which values I probably intended to return to) to maximum values.

I normally deal with this by using encoders in the hardware and relative response in Live. I keep track of the movements of the encoders with counters in MT, so I know when they’ve reached max and min values.

Is it possible for you to provide a version that just outputs one value (eg 41h) when the trackball moves in one direction and another value (eg 3Fh) when it’s moved in the other direction. Same for the Scroll Wheel. I know this is kind of backtracking in all the work you’ve done to get MB working for me, and I should have thought of it earlier. Hopefully you can see the value of this to other potential customers, which might take the sting out of my having waited till now to relate this.

Thanks …….. A LOT…..

Gabriel

7

Hi Gabriel,

Go ahead and give Y axis your best shot tonight and if you are stumped I’ll jump in.

As far as making these relative encoders, I guess the key thing to do is instead of sending absolute values just increment or decrement a global variable. Not sure how this will work with screen moves however, I guess instead of sending out a delta value, you could set a timer for the amount you want it to move and the repeat the timer delta times 3F for down and 41 for up. Then set Ableton to look for relative values. Make sense?
Most of the magic here is with MT-Pro rules. MIDIBuddy continues to just send mouse coordinates and lets MT Pro do all of the heavy lifting. I hope you are enjoying your new functionality using your trackball as a MIDI controller with MIDIBuddy!

Steve

8

OK, I’ll try to program the Y-Axis translator. I’ll let you know when I get it right (if I do).

As for the incremental vs absolute functionality, I thought it would be easier to do on the MIDIBuddy end. That’s because MIDIBuddy must be receiving incremental data, or lets say pulses that just repeat over and over as the mouse is moved in one direction, and then a different train of pulses if it’s moved in the other direction.

Instead of making that update a counter in MIDIBuddy, couldn’t you just send 41h every time MB receives a pulse signifying left movement, and then 3F each time MB receives a pulse signifying right movement.

Doesn’t this simplify the whole process by eliminating MB having to set up and increment or decrement counters, which in my MT code has to be unwrapped and then require timers in order to recreate the pulses that were sent?

9

Hi Steve,

I’ve given the Y-Axis translator 3 tries now, and just can’t get it right. I think the problem is that I’m getting confused by the way you are using local variables. pp qq rr and ss get their values from input from MB, but there are places in your code where you seem to be overwriting and reusing these variables – maybe in order to have enough local variables to do the job. For example:

//Scaling factor
vv=kr+1
qq=128
qq=vv/qq
// Adjust sensitivity
qq=qq/2
// qq is now our scaling factor this is the number
// of pixels we need to move before changing the
//controller value

In this section of code, you seem to be using overwriting qq (from MB) with 128, and then doing further manipulations to qq. I guess this is ok because you’ve gotten the information you need from qq already, but somehow I found this and similar uses of local variables later on in the translator.

So I tried and failed. I’d really appreciate if you would code the Y-axis translator for me. I notice you needed 3 more variables in this version. I use ix, im, and in already in the code, but was able to eke out n5, ll, and lk for use here.

I’m still hoping you see the logic in my thinking that implementing relative midi commands would be useful if it were in MB, available for use by MT (or even directly by Live or other programs).

Thanks,

Gabriel

10

Hi Steve,

Since I failed in my attempt to make the Y-Axis work, I thought I’d try to code for an incremental response to incoming MIDIBuddy messages. The attached file almost works. It would be great if you could find the flaw. The problem is that it seems to decrement more than it increments (or maybe it’s the other way round) and that rapid movements of the mouse instead of slow movements seem partly to be missed, (the effect is not as great then).

If you don’t have the time to do this, I understand.

Thanks,

Gabriel


Attachments:
1509095796896_maybe-incremental.bmtp
11

Hi Gabriel,

I’ll take a look at your file and let you know. Right Now MIDIBuddy sends out absolute mouse position only, I will consider adding relative positioning in the future. Actually if you freeze your actual mouse movement with the shortcut cntrl-alt F, it will do it now instead of absolute mouse movements. Of course your mouse will not move but you can use cntrl-alt U to unfreeze the mouse positioning. You can use controllers in MT Pro to convert MIDI to keystrokes to do this. I set it up this way so that the user could detect “mouse movement requests” to process these requests without actually moving the mouse. A user can use a MIDI controller to send a left mouse down only keystroke and begin to drag the mouse. Then if you attempt to move the real mouse, it can send this as a a MIDI message to Bome MT pro and MTPro can use this message to send a mouse up and then a separate message to release mouse movement. In this fashion, the mouse will not drag any further but will be come responsive after it is released. The MIDI message it says is relative (requested) mouse movement messages with the amount of pixels that you “attempted” to move the mouse. These could easily be converted with MT Pro to send out 3F and 41 relative movement messages.

The MIDIBuddy design is really to provide alternate means of input that MT Pro doesn’t natively support. I rely on MTPro’s super fast way of handling translation which MIDIBuddy doesn’t currently handle.

Again, I will play with your project later today so that you can achieve incremental movements using absolute mouse positioning.

Steve
bome@sniz.biz
Independent Bome Programming Specialist
Bome Q&A moderator

12

Hi Gabriel,

 

This should get you pretty close, however like the first go at absolute reverse direction there may be some sort of initial dead zone. Only when reversing direction of the mouse.

The new strategy is to capture the delta value and then set a timer to send out multiple 3FH or 41H depending on direction. I use the modulo operator in X-Position Timer Preset to control the sensitivity.

When the incoming MIDI is detected, it sets the direction and the number of iterations.

The timer counts down the iteration and sets the direction to 0 when done.

Direction of +1 is right and -1 is left and controls whether to send 3F (left) or 41(right)

When the timer is doing it’s thing the value of im will be zero and during this time new MIDI movement positioning will be ignored. I set the timer for the minimum 1msec interval to make it as fast as possible.

Give it a try.

Steve


Attachments:
1509119029956_incremental-2017-10-27.bmtp
13

Hi Steve,

That’s pretty close, but has some funny behaviour. It’s as if there was a rubberband attached to the mouse and it’s the rubberband that I hold on to instead of the mouse. I’ll characterize it this way:

  1. There’s a lag when I begin mouse movement.
  2. f I move quickly, I outpace the movement of the mapped panpot in Live
  3. But there’s momentum built up in the system, and if I stop moving the mouse, the panpot will catch up with my intended position
  4. If I move quickly in one direction (say left) and then change direction, the panpot will start slowly in the original direction.- slowly gaining speed, continue moving left (presumably until it reaches the intended left position) and then slowly start moving to the right, picking up speed. etc etc

So this method, sadly, doesn’t do the trick.

Gabriel

14

Steve,

BTW, it’s ok with me if you consider the incremental approach to be outside the scope of what you should be doing to help. If so, could you just get the Y-axis translator written and send me on my way. 😉

Thanks,

Gabriel

15

Gabriel,

Try this version.

I took out some parameters and it should be more reactive.

I also added 2 translators to control X movement while mouse is frozen.

To test hit control alt F – This will freeze the mouse and start sending relative mouse “attempted” movements which should move your controller.

When done hit control alt U to unfreeze the mouse and go back to normal operation.

If this works, then it should be pretty straight forward to make Y axis translators.

 

Steve

bome@sniz.biz

Independent Bome Programming Specialist

Bome Q&A moderator

 


Attachments:
1509128829544_incremental-2017-10-27.bmtp
16

Yes Indeed! With the cursor frozen the reactiveness, speed, and range are all excellent. If it’s not possible to get the same action with the cursor movement activated, perhaps we could devise a method to activate cursor movement only when I need it. One case in which I’d need it is when I position the cursor over the loop brace in Live and the click and drag it to the right or left. I need to see where the cursor is in order to position it correctly for that operation. Since I shorten the loop brace by adjusting its left and right ends, I can’t assume it will always be in the same place, so I can’t just position the cursor in the center, say, and always actually be over the loop brace.

However, if I can Freeze and Unfreeze the cursor with a button press (Hotkeys won’t work for me since the Laptop is pretty far from the rest of my setup) then that would work. Otherwise, it sounds as if you have a solution in mind.

Cheers,

Gabriel

17

You can set up a MT Pro to convert an incoming controller signal to a hotkey(shortcut).
You could even configure a mouse click to do this since MIDIBuddy sends out mouse click sysex messages.
I think the issue with the reaction time is similar to what we had earlier. So maybe we need to count cumulative mouse movements with the new methodology as we did when we were converting absolute movements.

18

Hi Gabriel,

 

I created a new MT Pro file for you to test with MIDIBuddy

I’ve set output to be all relative (3F/41) – In Ableton Jargon that means you set for Relative Binary Offset to test your knobs and/or sliders.

The only thing you will need to change for your setup is the output messages of the X Timer and Y Timer translators to the appropriate controller numbers you want to use in Ableton.

The translators I touched are as follows all under the “Work” preset:

9 – Ableton Mouse Movement X Position Test – Used for when Mouse is unfrozen

10- Ableton Mouse Movement Y Position Test – Used for when Mouse is unfrozen

11- Mouse Move Relative X – Used for when Mouse is Frozen

12-Mouse Move Relative Y – Used for when Mouse is Frozen

13-Ableton Scroll Wheel Test X

14-Ableton Scroll Wheel Test Y

All of the above translators start one of the two timers depending on the control

16 X Timer

17 Y Timer

The Timer translators actuation send the output. So for changing X control just modify the controller for 16 and for Y control, modify controller for translator 17.

I tested this and found all of the controllers quite responsive.

I have a sensitivity adjustment on 9-14. It it basically a multiplier for the repeat count of the timer (how many 3F or 41 the timer sends), so if it is not to your liking, that is all you should have to adjust.

In MIDIBuddy, I set the Delay to 10 milliseconds

You can use the new settings screen in MIDIBuddy on the build I created yesterday to make value persistent between sessions.

 

 


Attachments:
1509640093695_MIDIBuddy-Ableton-Test-Gabriel-2017-11-02.bmtp
19

Hi Gabriel,

 

I created a new MT Pro file for you to test with MIDIBuddy

I’ve set output to be all relative (3F/41) – In Ableton Jargon that means you set for Relative Binary Offset to test your knobs and/or sliders.

The only thing you will need to change for your setup is the output messages of the X Timer and Y Timer translators to the appropriate controller numbers you want to use in Ableton.

The translators I touched are as follows all under the “Work” preset:

9 – Ableton Mouse Movement X Position Test – Used for when Mouse is unfrozen

10- Ableton Mouse Movement Y Position Test – Used for when Mouse is unfrozen

11- Mouse Move Relative X – Used for when Mouse is Frozen

12-Mouse Move Relative Y – Used for when Mouse is Frozen

13-Ableton Scroll Wheel Test X

14-Ableton Scroll Wheel Test Y

All of the above translators start one of the two timers depending on the control

16 X Timer

17 Y Timer

The Timer translators actuation send the output. So for changing X control just modify the controller for 16 and for Y control, modify controller for translator 17.

I tested this and found all of the controllers quite responsive.

I have a sensitivity adjustment on 9-14. It it basically a multiplier for the repeat count of the timer (how many 3F or 41 the timer sends), so if it is not to your liking, that is all you should have to adjust.

In MIDIBuddy, I set the Delay to 10 milliseconds

You can use the new settings screen in MIDIBuddy on the build I created yesterday to make value persistent between sessions.

 

 


Attachments:
1509643886384_MIDIBuddy-Ableton-Test-Gabriel-2017-11-02.bmtp
20

Steve,

This is fantastic. My trackball is now mapped to several different Ableton controls (faders and pots) and the controls are faithfully representing movements of the trackball….Accurate positioning, no lag, no overshoot.

It took us a while to zero in on the problems I was experiencing and eliminate them but it was absolutely worthwhile. I think it required deep understanding in order to do the programming. Brilliant job.

I wonder if it’s possible to use 2 trackballs in a way that input from one is distinguishable from input from the other. Since two USB mice are essentially considered to be one and the same by Windows, I doubt that it can be done. Maybe you have some way of doing this?

Anyway, thanks a million. I may have a few questions relating to the translators you explained in your last post, but in all likelihood, I can figure it out myself.

Thanks again,

Gabriel