Since the new update, my series of actions are triggered very slowly.
The issue started the very minute the new update was installed.
**Affected input device : Touch Bar, keyboard shortcuts... anything that has a series of actions to be executed. The delay from one action to another is much longer than usual, making more complex triggers way longer to execute than it used to be.
MacBook Pro 16 in, 2019
Monterey 12.3.1
Is this a known issue ?
Is there a way to revert to an earlier version until the problem is fixed ?
haven’t heard of such an issue yet and by now most people have the latest version. Could something be slowing down your computer? Have you already tried to restart?
I had the same problem with version 3.781
Whether it's keyboard input or page scrolling, there are delays and lagging sensations
And I've noticed that in version 3.781 CPU usage becomes higher(About 5 percent)
All versions are available here: Index of /releases (but I'm really sure it has nothing to do with the current release, more likely it is caused by some specific configuration)
If downgrading, best create an export of your current preset first.
If you can still reproduce the issue (with the current version), please go to Help => Export Diagnostic Debug Info and send the result to andreas@folivora.ai, this will allow me to check what's going wrong.
That's what I thought Recent versions didn't really change anything that could affect performance.
In your case the log suggests that there is a USB device which keeps disconnecting (maybe not enough power?), this will cause BTT to constantly reinitialize and use a lot of CPU. I'd recommend to try disconnecting USB devices and see whether that helps.
I'm having the same issue. I'm using a custom action to show Mission Control including the desktop previews which is faster than the default one (desktop previews visible immediately instead of triggered and animated after triggering Mission Control):
– save current mouse position
– move mouse to 0.00, 0.00
– delay 0.04
– Mission Control
– delay 0.04
– move mouse to 0.00, 1.00
– delay 0.04
– restore saved mouse position
Has been working almost flawlessly for years, excepting rare situations with CPU cores at full from some other process, up until 3.756. Immediately started to perform extremely slowly with the next update (there were two for me, one whose version number I don't remeber and now 3.781, both affected). It's like it's hanging in between steps, and I can't pinpoint a single one which is the cause. The upshot is that upon triggering, sometimes Mission Control doesn't open right away, sometimes the mouse doesn't return to its original position right away, sometimes it doesn't even leave its original position right away. Not every time, but most of the time.
If I switch back to 3.756, all is fine again, and bad again if I update to 3.781 again—completely reproducible. Definitely not due to other apps or system processes.
I'm sending my debug logs for 3.756 and 3.781.
I'm on Mojave, but since @carlc1979 apparently has the same issue on Monterey, I doubt that's the issue.
"unfortunately" your example is still working fine here. However the mission control preview thing is very fragile when it comes to changes in timing (which is why the built in method is a bit slower, it ensures it works on all machines).
I'm not sure what would have changed.
@carlc1979 do you have an example which doesn't work correctly anymore? Is it only the "delay next action" action that's causing issues?
I just tried to output a few characters one after each other with your config, but it seems to work fine here.
Here is one of the series of actions that I use to mark a notification banner that comes in as ''read'' without having to click on it.
You are right, if I remove the delays, the series of actions are triggered swiftly one after the other without any problem (although the actual trigger is not functional, given the normal delay of response of my Mac).
When I add back the ''Delay next action'', the timed delays are much longer than usual / before the upgrade.
Given that the ''Delay next action'' is part of most of my series of actions in BTT it feels like it is everything is very much slowed down now.
FWIW, if I set every delay in my action chain to 1 second, it consistently performs it with 1-second delays. Same for anything longer. But at 0.5 seconds it already starts to get inconsistent, some delays take way longer (up to several seconds, especially if I trigger the action multiple times while the first run hasn't finished yet).
So it might indeed be a delay-related problem here as well.
ah that's interesting - triggering multiple times while the first run hadn't finished. Previously this hasn't been possible because BTT did block during the delayed execution. (So BTT would wait for the first to finish before starting anything else). However due to a important bugfix this might have become possible and maybe causes this issue.
I think I’ll be able to find & fix that with this information.
I did a relatively complex workaround in alpha 3.782 - would be great if you could check whether that does change anything for you. The thing @shnub mentioned (repeated execution before delay has happened) was definitely a bug, but I'm not sure whether it was the cause for your other issues as well.
I did some sleuthing and found out that 3.758 was actually the first version with the prolonged delay—3.757 was the last to perform normally. Perhaps that helps to pin down the cause? Obviously something must have changed in between those two versions.
Also, I did some more formal testing to quantify the prolonged delay. I created a custom action sequence with a number of identical delays, put an (async) AppleScript with just "beep" in it at the start and the end, and manually timed the total duration with a stopwatch. Basically, up until 3.757, it works out perfectly, with a difference in expected and measured delay time only for the smallest possible delay amount of 0.01 s. (And even that is negligible for practical purposes.)
Beginning with 3.758, however, there is an added runtime of at least 0.2 s per delay, and that goes up to 0.5 s when going below 1 s for the entered amount, making those short delays all but unusable. See this table for detailed results:
Summary
Number of repetitions was chosen so as to be at least 10 and ensure a total runtime of at least 20 seconds. Total runtime had 0.5 s substracted for stopwatch reaction time and was then rounded to nearest integer.
I also did some more experiments and just uploaded v3.783 alpha. While I can't go back to the way it worked in 3.758, I think the real delay should not deviate by more than 50ms anymore from the set value anymore.
If this still doesn't help, please send the debug logs one more time - I added some new log messages that might be helpful.
Good news: the worst "delay delay" I could measure with 3.783 was 18 ms, and more importantly, my Mission Control action seems to work flawlessly again. Yay!
Bad news: while delaying, BTT is now completely unresponsive. Any action triggered gets executed only after the delay period; even BTT's main window won't react to clicks and starts showing the beachball instead. This definitely didn't happen before. :-/
