A while ago, I made a macro to change the colour of objects automatically in Logic Pro, so that I could use a keyboard shortcut instead of having to use a mouse.
It opens the 'Color' window, moves it to a predictable position (top left), clicks on the colour I want, returns the mouse to where it was originally, and closes the Color window again.
Until recently, this happened so fast you could barely see it happen. Only if you really concentrated could you see that the Color window appeared for a split second. I was able to map this macro to a key command, and execute it during a flurry of activity in a fast workflow.
At some point recently, this Macro got slower. It now takes roughly half a second, or maybe a second - long enough that I have often already clicked the mouse elsewhere by the time the colour changes, so it ends up changing the colour of the wrong object.
I've experimented with disabling individual Actions in the Macro, and it seems that 'Move Window Named "Color" to Position' is the culprit - if I disable this Action, the Macro runs super-fast again.
I'm not sure, but I think this may have happened since upgrading to Keyboard Maestro 11, and also to MacOS Ventura.
Is there anyway of making this Action run fast again? Thanks!
If I've understood correctly, the issue seems to occur because Move and Resize are two separate steps and, to do both reliably, KM must introduce a pause to ensure the first step is fully finished before moving onto the second step.
In my Macro, there is only the one Move step - in fact, the Color window is fixed-size, so cannot be Resized. Since there is no danger of Actions overlapping in this case, there is presumably no need for the delay. Is there any way of executing just the Move step without it?
The way I understand it is Apple’s API handles both moving and positioning, regardless of which KM action is used. But Peter would need to confirm/deny that.
The issue is that your next action might be Resize a Window, the action would not know that without looking ahead to see what would come, so the actions, by default, include the delay after either half of the move / resize.
It is possible to disable just the single use case with a separate command
This affects only the single-step actions (Move or Resize) while retaining the mitigation for the Move&Resize action. But it leaves you open to the bug if you do a Move action followed by a Resize action.
I'm really unimpressed with the whole situation, adding pointless delays to avoid bugs in Apple’s code when it sometimes animates the changes is utterly unacceptable. But screwing up the action is worse, so hear we are.
