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


Attachments:
1512511168554_MOUSE-SUPPRESS-PREVENTS-LOCKING-CURSOR-TO-LOOP-BRACE.als
1512511278127_MOUSE-SUPPRESS-PREVENTS-LOCKING-CURSOR-TO-LOOP-BRACE.als
1512511206481_MOUSE-SUPPRESS-PREVENTS-LOCKING-CURSOR-TO-LOOP-BRACE.bmtp
1512511278127_MOUSE-SUPPRESS-PREVENTS-LOCKING-CURSOR-TO-LOOP-BRACE.als

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?