I just released a new build of MIDIBuddy that includes the ability to assign different outgoing MIDI message based not only on the button or scroll wheel used, but also for each attached mouse.
For instance you can now have each mouse control send unique midi messages. As an example you can use the scroll wheel for the first attached mouse to send a different message than the scroll wheel for the second attached mouse. This opens up a whole new world of possibilities for using any standard support mouse to act as a MIDI controller for your devices or apps.
MIDIBuddy is supported on Microsoft Windows Only. Only tested on Windows 10 but very well may work on other versions of Windows as well.
I forgot to mention that the little pop-up telling me that the mouse is paused is a classy addition. Thanks.
As for the new bmtp and code… Generally, it’s working, and each mouse function is indeed recognized as unique, but the reaction to mouse x-axis and y-axis isn’t smooth anymore. Well… it is at certain speeds of mouse movement, but if I move the mouse slowly or briskly, the action on mapped Live pots gets strange. The pot might follow mouse movement for a bit, then it gets stuck, then moves hesitatingly, then moves along as it should.. etc. Sometimes there’s no action at all, as if the mouse were paused, but if I keep moving the mouse in the same direction, eventually the pot starts reacting and will follow mouse movement faithfully. But it’s all pretty iffy. Something seems to have been broken.
As usual, I’m tied up until later tonight, but I’ll see if I can find something I’m doing wrong, or if I can find what the code might be doing wrong.
Wait… I think you’re now sending the other kind of relative message…. 7F for increment and 01 for decrement. and also 7E, 7D, etc etc for faster (or slower?) incremental movements and 02, 03, etc for faster (or slower?) decremental movements. I haven’t had a chance to really check this out, just saw it as I was shutting down, but it makes sense in relation to what I’m seeing. I’ll look into it later tonight.
Gabriel,
I recommend you use the timer method as we had it in the last BMTP file I sent you. The template file is just that, a template to start with and is not intended to be your specific implementation. Glad you like to tool tip!
Yeah for the template I decided to not use the timer so instead of 3F 41 it is probably like 38 48 to make the mouse wheel a little more reactive. You can play with the numbers and of course go back to the timer method if that works better for you.
Please check the inputs you get for Translator 3/14 and 3/15 when moving your mouse. What I see is confusing, and may be the basis for the problems I’m seeing. I’ll list the outcome for moving the mouse. It keeps my train of thought manageable. I hope it’s not to plodding for you. Note, especially, 14 below:
Move mouse as smoothly as possible (meaning same speed) as I can to the right.
Input from MIDIBuddy is consistent and comprises numbers below 64.
For example inputs are 01, 02, 03 etc. depending on the speed with which I’m moving the mouse.
These values change since I can’t always keep exactly the same speed of motion.
I interpret anything below 64 as being equal to 56 and send that value to the mapped pot.
The mapped pot is type Relative (lin BinOffset).
If I move the mouse in the other direction I see values consistently about 64.
These values are 127, 126, 125 etc… again, dependent upon speed of mouse movement.
I interpret anything above 64 as being equal to 72 and send that value to the mapped pot.
I chose 56 and 72 because these scale the motion of the pot so that it responds in reasonable steps.
SO FAR, SO GOOD.
However, the input stream is not steady. Even if I move the mouse quite steadily…roughly the same speed…the input from MIDIBuddy is coming in spurts. It will stream in quite steadily for a short while (maybe 1/2 second) then pause, with nothing coming in at all. Then I see input again for a while, then nothing – etc etc. Sometimes the pauses are longer.. sometimes shorter.
BTW, up until this point, wasn’t MIDIBuddy sending only 3F for decrementing and 41 for incrementing? It doesn’t really matter much since I can interpret that type of incoming message or the way it’s being done now. I know the advantage of using variable messages to represent different speeds of mouse movement. I just don’t like how that affects pot movement. Not a big deal.
MIDIBuddy never sent out 3F 41. This was all coverted by Bome MIDI translator. MIDIBuddy sends out the actual pixel increments/decrements where 7F is negative 1 7E is negative 2 etc. This behaviour has not changed. Any changes I made in this regard is within the project file of Bome MIDI translator.
Have you tried the mouse movement with the last working version of BMT project. THe template file is just an “example” and not meant to be your final solution. If you remember, we spent days getting this right in the past and ended up using timers. Since MIDIBuddy output has not changed, you will likely need to go back to the timer method for your solution. I can check the behavior using the old project file if you would like just to make sure I didn’t break anything in MIDIBuddy, but I don’t think I did since the output has not changed.
Hi Gabriel. I just tested mouse movements with the Test Project I posted the other day MIDIBuddy Ableton-Test-Gabriel-2017-11-10. I tested translators 1-11 1-12 and their companion timers 1-20 and 1-20 and everything looked OK.
So what you may need to do is modify your production product file as such. Again the template is just that (a template) and not meant to be a complete solution as everyone will be doing things different with MIDIBuddy.
Of course for each of your mice you will need to set up separate global variables and timers which I didn’t do for testing.
The last release fixed the hesitations in MIDIBuddy response to mouse movements. I couldn’t be happier. It distinguishes between two mice, their x and y axis movement, left and middle buttons, scroll wheel x and y movement. I don’t think I’ll be using a joystick, but I guess some people will latch onto that capability.