Any way to prevent scroll wheel from scrolling and just send a MIDI message via MIDIBuddy?

MIDIBuddy does a nice job of sending MIDI messages in response to scroll wheel movement, but it also causes scrolling.

In my Live set, there are 60 rows.  They can't all be displayed at once, and the scroll wheel does indeed cause the Live window to scroll. This can cause  some of my actions to miscue in Live, since the screen shifts.

Is it possible to capture the scrolling function before it gets sent to Windows but still allow MIDIBuddy to generate MIDI messages (as you did for the right button clicks)?

thanks,

Gabriel

I’ll have to check the Readme file and I’m not on my Windows computer right now. Will let you know but if I remember you hold the “special” key and the actual mouse function is suspended with MIDI messages only.  If I remember the default “special” key is ALT but you can change that in the settings. You can also reverse it so that when released only MIDI is send and when pressed the mouse function as well.  The “special” key is use for all mouse functions though.  Again I’ll check my notes and confirm but you can also see in the Readme file that you downloaded with MIDIBuddy.

 

Steve

 

Yes indeed, the special key suppresses mouse function.  I’m not sure this does what I need, though.  I’m checking now and will get back to you.

Gabriel

The Special key does do its job.  Is it possible to make a refinement?

Only MIDIBuddy generated messages are utilized when I’m using the trackball, so I would use the special key in its reversed mode. Perfect!!!

However, when I use the mouse, I need the mouse clicks …..HEY.. WAIT A MINUTE…. I think it’ll be just fine.  I can make MIDIBuddy send mouse clicks instead of using the Windows system generated mouse clicks.

Let me just check that, but I think it’s true – and solves the final problem I thought I had.  I imagine you don’t really believe it’s the last thing I ask you to consider changing 😉   Anyway, I’ll let you know.

Thanks,

Gabriel

Yes, the best way to re-enable mouse actions on a given mouse after disabling them with the special key is to have Bome forward the mouse action back to the application for those mice/trackballs you still want to operate.

 

Here’s a mystery…

When I use the Special key (In my case Alt) to suppress key presses, I then field MIDIBuddy output in Midi Translator, and in response to a middle button press of the mouse, I send a Left Mouse button down to Live.  The mystery is that though the Mouse button down is sent from MT, Live never responds to it.

Any ideas?

Hi Gabriel,
What window has the focus when sending the mouse down button? Remember keystrokes and I believe mouse clicks are suspended if MT Pro has the focus unless you have change the settings otherwise. If that doesn’t work, you can try “injected’ mouse clicks but I don’t think you will need them. I’ll see if I can replicate the problem on my system since I also have Live. I know that some applications don’t respond to MT Pro clicks or keystrokes but I don’t think Live is one of them that has this problem. Where in live are you sending the click? What action are you trying to accomplish?

Steve, It’ll be easier to post the MT and Live files than to explain.

What you need to know to test is this:

• Launch Live and MT and load the Live Set and MT project.
• In Live, double click on the name of the clip called NicosDream.  This will display the clip at the bottom of the screen.  You’ll noticed that the loop is set to be only a portion of the end of the entire clip.
• Now click the arrow just to the left of NicosDream to start it looping.
• Now press the middle mouse button and release it.  This will:
• — Move the cursor to hover over the loop brace
• — Release any left mouse down that happens to have lingered on somehow in error.
• — Do a left mouse button down (only down, not down – up)

This results in the cursor being locked to the loop brace so that mouse left/right movements drag the loop brace around.  This moves the part of the loop that plays.

The problem is that if you do the above with the Special Key pressed, or if the Special Key function is reversed so it’s always suppressing mouse button movement, Live does move the cursor to the correct position, but seems not to receive the left mouse down, so the cursor doesn’t lock to the brace.

I found that I could avoid this by putting a one second delay before the mouse down is sent to Live.  This allows me to lift the Alt key, effectively ending the suppression, but that’s not really feasible when playing.

Not sure I collected the clip in Live in the first attached set.  Second set will have it if the first doesn’t.

Gabriel

I should add that MIDIBuddy should send on BMT Virtual in 7. Also, the trackball is seen first… mouse is second. I think my code blocks the middle button press unless it comes from the second mouse.

Hi, I’ve found a bug in MIDIBuddy. Working on a fix now

Hi, Gabriel,

I just send you a link via email to the latest MIDIBuddy built.  I believe the problem is now fixed. Let me know.

 

Hi Steve,

You may be misinterpreting what I state as the problem, because I don’t see a change in action in this latest release.

I have another observation about the problem though.  If you launch the Live set and my MT project I sent you last “MOUSE SUPPRESS PREVENTS LOCKING CURSOR TO LOOP BRACE”,  and follow the directions I gave you last time (repeated below), I think you’ll see that even though the MT logfile shows a left mouse button down click being sent, as it should be this doesn’t seem to be picked up by Live, because the cursor doesn’t lock to the loop brace.  If it did lock, just moving the mouse  right/left will move the brace even if the middle button is release.  The strange thing is that if I send a real left mouse down click (once the cursor is positioned over the brace), then the cursor is locked and moving right/left does move the brace.  I don’t want to have to hold the middle button down though, which is why I try to send the left mouse click down (only) when the middle button is pressed.

Let me know if you see what I am seeing.

Gabriel

I’ve been meaning to tell you that I think the tooltips should fade out after a while, especially the one about suppression. It blocks off some things I need to see in Live. I can see why you’d like it to remain displayed. Without the notification, one might forget that suppression is in effect. But the fact that it blocks part of the Live screen is a hinderance.

Hi Gabriel,
I will look at your specific scenario today. I had to first fix a bug that I found in MIDIBuddy and I expect suspect it is related to the problem you are experiencing. Although MIDIBuddy was sending out mouse messages and MT Pro was sending them back as clicks, MIDIBuddy were also blocking clicks sent by MT Pro. I validated it was fixed in the build I sent yesterday but I did not look at it with your specific scenario.

Steve

I think I have it fixed now. Sending you a new build of MIDIBuddy
Also status box for reversal goes away after 5 seconds, however if you try and click, you still get a temporary tool tip reminding you that mouse clicks are disabled.

Hi Steve,

with this release, I get exactly the response I need (cursor locks to loop brace) if there is no  mouse button suppression. This is fixed from the last version, where I couldn’t get locking regardless of suppression.
I think maybe what’s happening is that
– MIDIBuddy is sending correct information to MT
– MT responds by sending the correct MIDI commands to Live
but
– Somehow Windows knows that the suppression is in effect and blocks the final MT output (Left Mouse Button Down) from reaching Live.  So – no cursor locking to the loop brace.

Strangely, the initial MT cursor position command is not blocked, but maybe that’s reasonable to expect because it’s not being suppressed.

Maybe it would be possible for the Middle Button press to temporarily un-suppress mouse button information.  If this could be done after the cursor position is established, then the context menu pop-ups wouldn’t happen (There’s no context menu when cursor is in that position). Then the suppression could be re-established.  Possible to do?
Thanks,
Gabriel

Shoot, thought I had it. I’ll look again

I think the only way to judge whether or not it’s fixed is to test it with the files I sent.  Just looking at what MIDIBuddy and Midi Translator are doing doesn’t disclose the mechanism.  They seem to be working perfectly.  MIDIBuddy reports mouse info correctly to MT.  MT responds correctly when it sends MIDI commands to Live, but that MIDI info – specifically the Left Mouse Button Down – seems never to get to Live. It’s something hidden – perhaps within Windows itself.

Gabriel

I tried a work-around, and it works, but I don’t know if it’s possible to send Ctrl Alt R to MIDIBuddy from Midi Translator.
So…
– Send Ctrl Alt R to MIDIBuddy to implement suppression.
– Click Middle mouse Button and hold it down.
– MT then correctly sends a mouse position command to Live, and Live responds correctly
– Without releasing the middle button, send Ctrl Alt R to undo suppression.
– Now release the middle button
– Middle button release causes MT to send Left Mouse Button Down
– Since I sent “unsuppress” message to MIDIBuddy, the Mouse Button Down is received in Live and Live reacts accordingly by locking the cursor to the loop brace.

OK, so next, I’ll try sending the unsuppress message from MT instead of by pressing physical Ctrl Alt R. Maybe that works.

No luck. I guess I don’t know how to get Ctrl Alt R to MIDIBuddy. I tried sending the message to Live, but that doesn’t get to MIDIBuddy. How can I send messages to MIDIBuddy?

I previously used Autohotkey to lock the cursor to the loop brace. I did this by first using the mouse to position the cursor over the loop brace, then pressing the middle button. My Autohotkey script then sent a left mouse button down. Curiously, this doesn’t work when button suppression is invoked by MIDIBuddy.

Even more curious. I had another way of locking the cursor to the loop brace. I pressed a button on one of my Akai APC Mini controllers. Ths also sent a Left Button down command from MT. This also is blocked by the suppression in MB.

So… again, could you explore the possibility of sending a temporary unsuppress just before the Left Button Down message is sent?

I’m testing with your files. Here is the current MIDIBuddy Behavior. By handling your ALT behavior request you made some time back, it doesn’t work exactly as you requested. Normal Behavior ————— Mouse button pressed no Send Mouse Button and MIDI Push Special Button to Suppress Mouse Click Reverse Behavior —————- Mouse button pressed no Pressed. Send MIDI Only Push Button to send Mouse with the Special AND Mouse Click with MIDI — So in your translator if you see that mode is enabled, You will need to send Alt Down, Button, Alt Up from MIDIBuddy (assuming you are using Alt ask the I’m trying to get it so that it will take the mouse click without the Alt (from MIDI mouse only) but that is where I’m having problems. You can test with the above behavior if you would like, I send the following MIDI string when Reverse Mode is invoked Reverse Mode F0 7D 42 4F 4D 45 7F 02 0B F7 Normal Mode (Assumed ad MIDIBuddy Startup) F0 7D 42 4F 4D 45 7F 02 0C F7 You could use these to set/unset a global variable to enable/disable special down and special up translators In the meantime, I’m working on MIDIBuddy to change the behavior as you expected.

We’re using different words to describe what’s happening, so I’ll tell you what I think you’re saying, so I’m sure I understand.

Your words:

Normal Behavior
—————
Mouse button pressed no    <Gabriel> This means the state of Mouse button is “Not Pressed”

Send Mouse Button and MIDI  <Gabriel> This means Press Middle Mouse Button with the effect that MT sends Mouse Position and then sends Left Mouse Down

Push Button to Suppress Mouse Click  <Gabriel>  I don’t know why this is here.  I don’t send another button to Suppress Mouse Click.  What button would I be pressing?  At this point, the cursor has already been locked to the loop brace.  Nothing else needs to be done.  The only problem is that the right button context menu comes up anytime I use it, which can lead to errors.  That’s why I originally suggested suppressing right button… at least suppressing it’s context menu behaviour.

Reverse Behavior   <Gabriel>  Sorry, I really can’t understand what the statements below mean.  I’ll give it a try though
—————-
Mouse button pressed no Pressed.  <Gabriel> Does this mean start with Middle Button pressed and then release it?

Send MIDI Only  <Gabriel>  Does this mean send MIDI without sending a command to windows to display the right button context menu?

Push Button to send Mouse with the AND Mouse Click with MIDI  <Gabriel>  I don’t understand this at all.
—
So in your translator if you see that mode is enabled, You will need to send Alt Down, Button, Alt Up
from MIDIBuddy (assuming you are using Alt ask the   <Gabriel>  I think you’re saying that, in order to temporarily stop the suppression, I would need to send Alt Down.  That’s correct, it would work, but I don’t want to have to access the laptop keyboard to do it, and don’t want to load my mind down with the need to do it in the first place.  I was hoping to be able to send the Alt Down from MT somehow, but don’t know how to do it.

I’m trying to get it so that it will take the mouse click without the Alt (from MIDI mouse only) but that is where I’m having problems. You can test with the above behavior if you would like,

I send the following MIDI string when Reverse Mode is invoked
Reverse Mode
F0 7D 42 4F 4D 45 7F 02 0B F7  <Gabriel>  This is the MIDI String sent from MIDIBuddy to invoke Reverse Mode, correct?

Normal Mode (Assumed ad MIDIBuddy Startup)
F0 7D 42 4F 4D 45 7F 02 0C F7  <Gabriel>  And this is what MIDIBuddy sends on startup, which invokes normal behavior.  Right?

You could use these to set/unset a global variable to enable/disable special down and special up translators  <Gabriel>  Does this mean that if I have invoked Reverse Mode, I could undo it temporarily by sending F0 7D 42 4F 4D 45 7F 02 0C F7 to MT.  I don’t get it.  How would that affect anything? What would MT be expected to do if I sent this string.
In the meantime, I’m working on MIDIBuddy to change the behavior as you expected.

One more piece of info:
– If suppression is in effect, using physical LEFT mouse button down to lock cursor to loop brace doesn’t work.
– If suppression is in effect, but I press ALT, using physical LEFT mouse button down to lock DOES work.
However, If I try to lock cursor to brace with the MIDIBuddy routine, which also sends out the LEFT mouse button down, this left Button from MT does not seem to reach Live, and no locking occurs.
BTW… if my descriptions are baffling to you, maybe we should establish a common terminology for these actions.

anyway, I’m not sure how the messages sent to MT from MIDIBuddy affect the behavior I’m having problems with. Whether or not Reverse Mode is invoked, MT sends the Left Mouse Down message to Live. It’s something else that’s preventing Live from receiving or maybe reacting to that message.

Hi, I’m using a remapping technique. This doesn’t actually suppress keystrokes. It simply redefines them. I won’t go into much more detail because I’m actually trying to get it to work the way you want to behave.
In the meantime, in reverse mode you have to send altdown button altup. In normal mode just the button. Whether from mouse or from MT Pro. Anyway that is the way it behaves now. Yes the strings I sent you are to signal MT Pro whether it is in normal or reverse mode so MT Pro would know what to do.

OK, thanks for keeping at it.
I’m not quite sure what you mean by “Yes the strings I sent you are to signal MT Pro whether it is in normal or reverse mode so MT Pro would know what to do.”
It seems to me that MT is sending out the same messages whether or not the suppression is in effect. It seems to be in Windows itself that the suppression is happening, regardless of what’s happening in MT. But I think I should stop pestering you so that you can attack the problem in peace. No need to answer my statement.

Sending you another version shortly. Hopefully it will behave as you like. Had to do major surgery so hopefully no other side affects. I keep old versions so we can always get you back to a known state if this hoses things up.

This version should behave as follows Normal Pressing Click on real mouse sends click and MIDI message Pressing Special and Click on real mouse suppressed mouse action but MIDI sent Sending Click from MIDI Buddy sets click message Reverse Pressing Click with no Special sends MIDI message but no click Presssing Special plus click sends Special plus click plus MIDI message Sending Click with not special from MT Pro sends click I think this is what you are asking for. So you can put in Reverse Mode Press middle mouse button. Only MIDI message sent to MT Pro (no mouse click) MT Pro takes MIDI message and sends Left Click Down You should now be able to drag the loop. New version link in your email build:=”2017-12-06-16:49”

Steve,
I don’t see a link in my email…
Gabriel

Oh… I see it. You sent it and then the Forum sent a notification, so I missed it.

By Jove!  I think you’ve done it.  I haven’t tested in all circumstances, but trying it a few times – It works exactly as I hoped for.

I’ve got to walk the dog (no kidding) but will be back soon to test extensively.
Congrats,
Gabriel

I’m not able to test the new version because of a strange artifact.  I haven’t kept track of the actions that lead to the problem, but at some point after trying Reverse mode and also non-reverse mode, the cursor disappears when I move it over the Live window.  If I resize the window to, say, half size, I see the cursor when it’s not over the Live window, but when I move the cursor over the Live screen, it’s as if the Live screen obscures the cursor.  If I start a second instance of Live, the cursor shows up if its over this second instance.

I’ll track down the events leading up to this.  As for the Reverse mode etc etc, all else may be working well.

Gabriel

Very Strange, I’ve heard of users complaining of this before with Live but I’ve never experienced. I’ll see if I can duplicate the behavior and figure out what is happening.

Don’t spend too much time with this. It doesn’t happen all the time, and I’ve only experienced it one more time since I first reported it to you. Let me try to pin it down a bit more first. A clue might be what happens when you detune a clip. Try this:
Click a clip so it starts playing. At the bottom of the screen you should now see the sample waveform, and to the left of that, 3 or four panes, one of which is labeled “Sample” In that pane, you’ll see a transpose “wheel” , and under it, the word Detune. Under that there is a spinner – A horizontal bar. Click and hold on that spinner. The cursor will disappear and you’ll be locked on the Detune bar, which will change as you move the mouse up or down. It transposes in cents. When you release, the cursor reappears.
Maybe something like that is involved. I do have my code do this automatically in response to some MT commands, and maybe I invoked this, but couldn’t release the locked state. It’s not quite that simple since I didn’t see the detuning happening, but something similar might be in play.
I’ll let you know.
Gabriel

With the 12/6 version I’m now getting very confusing results. When I press Ctrl Alt P to pause mouse movements, the mouse movements do stop, but also the suppression message comes up as if I had also pressed Ctrl Alt R.  Then I’m in a weird state where I can’t tell how to enable mouse button presses or enable mouse movement.  It seems somewhat random,  Perhaps because of my choice of Alt as the special key (I’ve tried other choices as well, but something is still amiss.

As for the disappearing cursor, it did happen once more.  I was reaching awkwardly for Ctrl Alt P while holding the mouse in the air to prevent movement until I could prevent it with the pause function, and might have hit some other combination of hotkeys which hides the cursor somehow, but I was unable to duplicate it.

For now, though, I’m unable to go further until the Ctrl Alt P vs Ctrl Alt R mixup is resolved.  Do you also see the same thing?

We were so close to having the solution, and then something seems to have blown up.  Maybe it’s just me.  It’s pretty late and I’m pretty loopy.

Gabriel

Hi Gabriel,

I didn’t do any regression testing on Pause function as I was in a hurry to get Reverse function working for you. With that said in looking at my code. Pause will stop ALL outgoing relative MIDI messages from MIDIBuddy, including those that your are trying to re-route via MT Pro. It was put in place primarily to be able to stop outgoing MIDI messages while you were setting MT Pro or other MIDI device functions. You might be seeing two tool tips (one for Pause and one for reverse). Pause will override Reverse so you will have to toggle pause back off before you re-invoke reverse toggle. I’ll look at what to do about having multiple competing tool tips. I think I can show both simultaneously. I know the reverse tooltip is only there when you are touching the mouse where pause should be there whether you are touching mouse or not.

I recommend you don’t use both simultaneosly but if you do you will need to release pause before toggling reverse.

I’ll do some testing today and also see if I can figure out if the hidden mouse pointer is a problem with MIDIBuddy or the problem other users are reporting with Ableton Live.

Steve

My guess is that there is a certain mouse, keystroke combination that makes this occur and it may occur more often when doing the fancy stuff we are doing with MT Pro and MIDIBuddy. For instance on a normal mouse, you probably will not be hitting many (if any keys), while holding a mouse button down but if you send a mouse down message automatically with MT Pro, there is a lot of other stuff you may hit before sending a separate mouse up. There are several posts on Ableton Live about “missing mouse pointer” and they all seem to recommend resetting the Windows Mouse Driver or changing screen magnification.

So where is the state of your project after the Pause function discussion. So far for me things seem to be working as advertised after yesterday’s fix/enhancement.

Note, it was really not a bug because it worked as originally advertised but I worked on it because what you were wanting seem to be more intuitive than the implementation I had. I still might tweak with it a bit,

I really don’t want to send Alt-Mouse Click when the Alt Key is pressed, I would rather only send real mouse clicks and use the Special Key to merely signal MIDIBuddy whether to suppress or not suppress the mouse click.

So the next question is, What if you really want to send Alt-Click while holding the Alt-Key down? Right now I think I would like to keep it simple and not support combination Keystroke Mouse combinations.

Hi Steve,

I haven’t dropped the idea of using MIDIBuddy with a trackball for controlling Live, but have come up against a problem which I can’t solve.

X axis control works perfectly.  Y axis control works perfectly.  But this is only when only one axis is involved in Live control.  When they are both mapped (to different faders or knobs in Live) at the same time, I can’t get them to work entirely independently of one another.

If I do an extended Y axis movement, the X axis will seem to drift – mostly in one direction, but somewhat erratically – sometimes jittering back and forth.  The same is true for X axis movement affecting the Y axis.

This isn’t as pronounced when I use a mouse instead of the trackball, but it’s still there to a lesser degree.  I think this is in the nature of the physical “architecture” of the trackball.  As I move the ball up or down with my fingers, they don’t necessarily stay exactly centered over the ball.  My fingers might go slightly to the left or right of center, and when I do this, there would necessarily be some right/left movement as the ball would spin in that direction too.

I’m not sure that this accounts entirely for the problem because, even if I try to make up for the errant axis movement by moving my fingers diagonally, I don’t get absolute independence.  And anyway, this would be counter intuitive as far as controlling x and y.

The only solution I can think of is to monitor x and y movements relative to each other, and to lock x movement if y is the prevalent movement… or maybe just suppress it somewhat.  In my analog joystick, there isn’t the same problem, since it uses absolute rather than relative control. Also, there is some resistance to movement in either direction, and when the intended movement is in the Y dimension, most of the force is applied in that direction, and less force is applied in the X dimension – so the stick doesn’t tend to move at all in the X dimension.

Hmmm.  Maybe going back to absolute control with MIDIBuddy would be the solution.  I’ve lost track of the iterations of MB and of the MT project files that accompanied them.  I don’t know which one might have had a reasonably good solution for absolute movement.

I’d really appreciate it if you could resurrect these files for me so I could try that approach again.

Thanks,

Gabriel

Hi Gabriel,

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.

Regards,
Steve

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

OK, as I said, I actually like the thumb operated track ball now that I’m use to it.

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.

Thanks,

Gabriel

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

Sure, I’ll take a look are you on the 11/16 release?

Yes…. 11/16 version.

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.

Watch what happens to Pitch if you put the secondary screen to the left of the primary and move cursor from primary to secondary screen

Hi Steve,

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

Hi Gabriel, I’ll take a look at this sometime today and let you know.

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.

 

Hi Steve,

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?

Thanks,

Gabriel

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.

Hi, Gabriel,

 

Try this. Set the Pitch to Relative BIN offset for X position. I’ve converted from absolute to relative in the translator but left the scaling to 15.

 

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.

Hi Steve,

In order to control the dead zone in Left/Right movement of the trackball, I’ve found two solutions.

1.  When doing programming related to MIDIBuddy, I just watch the cursor, and visually make sure I don’t move it onto the secondary screen.
2.  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.

Thanks,

Gabriel

Well MIDIBuddy really does nothing with the space bar so maybe your keyboard is having a problem?

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

Are you also running Bome MIDI Translator when the space bar is not working? If so, please send me the project file.

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.

oh… my special key is ALT.

Thanks Steve. Deleting the .ini file did the trick.
So… now…
Question of the Day: did any of the versions of MB have unique absolute mouse movement?

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.