How about one push, turn, let go, mouse returns? I mean you're pushing the encoder that you're about to tweak, so that seems like it would become second nature.
Just a quick note on the first, while I remember...
If the "Knob DEC", "Knob INC", and "Knob Button" actions are mutually exclusive for each triggering of the macro then you'll save some time by using a "Switch/Case" action rather than chained "If"s. That's because "Switch" exits on a match, while all the chained "If"s are evaluated (even if the first is true), Put the most frequently seen first in the "Switch", least frequently last, for even more speed.
It normally wouldn't make much difference, but you're trying to work with a 0.5 second delay so every CPU cycle helps!
Here's an interesting thread. Hard to know what to make of it without having a Midi Twister, but it looks like Bome can create macros including mouse positioning and scroll simulation. If there's some kind of action in there that can ignore the first few midi values, then it could give the mouse time to move before affecting the intended control. I dunno; I'm just thinking out loud.
I know you're not that keen on using Bome or the MT's built-in scrolling, but I think there may be a better solution in one of those options than bombarding KM with midi messages, which isn't really something it's designed for.
Good hint - Thanks ! I can imagine that this helps to slim down the data flood significantly...definitely will implement this change.
Thanks Neil for the link ! That really sounds interesting and worth it to check out - especially the option of starting the output (scrolling the mouse) with a slight delay....! Sorry for refusing to the idea at first...
1 Like
Here's a theoretical idea that I think might work. These macros demonstrate the logic, but I can't test it as I don't have Bome, a MidiTwister or Pro Tools.
MidiTwister.kmmacros (65.5 KB)
- MidiTwister - Begin: Moves mouse, activates MidiTwister - Current, executes MidiTwister - End, activates Bome midi scroll, disables itself.
- MidiTwister - Current: Logs all incoming midi
- MidiTwister - End: Checks for midi inactivity at set interval, deactivates Bome midi scroll, deactivates midi logging, restores mouse position, enables MidiTwister - Begin ready for next run.
Thanks. I'll check that soon. As for now I can't MTP get to work properly at all....doesn't output the mouse wheel data although everything seems to be set up correctly (there's even a video by Bome on YT with the exact task and setup (Midi Twister controlling mouse scrolling)....no success so far....I'm investigating that in the MTP forum now 
I forgot to explain another point why this won't do the trick for me - the reason for setting up a separate command for the pushbutton on the MIDI Twister is to use that for separate functions, for example pushing performs an alt-Mouseclick on the GUI knob, resetting it to default position....
Oh man....Midi Translator Pro just don't work at all on my machine.... 
So in order to try any MTP-based things I need to fix that issue first...
By the way I've noticed another problem using the button function on the MIDI Twister....since the rotary encoder is stepless and kind of sensitive I often have kind of a cross-trigger from the encoder while pressing the knob as a button. So this must be considered for the programming as well....
AND: Anyway the problem still exists that the timing of the performed (order of) actions is not stable and reliable....
Just performing the simple (single) action of option-clicking with the mouse at a screen location sometimes results in option-clicking on the initial location instead - so KM seems to get confused with processing its own commands.... 
Probably not KM, but Apple's Event Processing queue. If you are doing "Move the mouse" as an action, then "Click at 0,0 to current" as another you're at Apple's mercy -- there's no "mouse has arrived" event returned for KM to listen for so it can't wait. You either have to include a set "Pause", a "Pause until %CurrentMouse%", or similar.
If you know the co-ordinates you need to move to and sometimes you need to click (as in your MIDI Twister example above), try doubling up for safety, ie "Move to 2256,168" and then "Option-click left at 2256,168".
Maybe, but I'm not talking about two separate actions here but only one (lets call it native KM) action like this:
I mean at least this should be posssible for KM to perform "in time", shouldn't it ? But I know that you know so much more than I do regarding the inner processes of KM and Mac OS processing......thanks for the tip of double-checking the mouse positioning with a separate "move"-command in addition to "move and click"....will test that....
At least I'm up and running now with Midi Translator Pro which also is capable of some cool tricks - maybe the combination of MTP and KM offers some great opportunities to even out each one's weaknesses somehow....sometimes more is more
Interested to see if you think this might fit with how Bome works or if some of the KM side can be done more directly.
I don't know much. But I've dimly-remembered Hypercard programming "gotchas" (Hypercard was all about Apple Events) and what I'm inferring from KM's observed behaviour. Eg:
And yes, I'd also expect that to work. That it doesn't, that the click sometimes happens before the move completes, suggests that the one action results in two Apple Events, "mouse move" and "mouse click". This might be a case when you have to go the other route, separate the Events yourself so you can control them better, and do a "mouse move" action, a "pause until %CurrentMouse% is..." action, then a "click at" action.
As I understand it (and you should assume that everything I say starts with that!) KM macros send Apple Events which are then passed by the OS to the appropriate process (a system process for things like mouse movement, directly to the app for an app's registered Apple Event, etc). In these days of "asynchronous everything" the old first-in-first-out Event queue is open to... let's say interpretation... and things may get in a pickle when things that developers assume will happen at "human speed" are done much quicker by something like KM.
Pure speculation on my part, but it does fit the observed behaviour, eg KM's "Type a string" being fine in some apps but dropping characters in others unless you slow things down.
Thanks for sharing your thoughts.
Yes, this makes total sense to me....was already wondering how the KM engine (or other comparable apps) would handle such combinated processes / commands...as always one has to adapt to whatever pecularities come with a certain app or framework. This might be one of the examples....
Using ControllerMate for years on my old machines I would always experience the same process of finding out what to tweak around those litte timing issues....now I need to go throgh the same learning process with KM...