Changing TinyTask Playback Speed

Click Prefs. The speed options sit at the top of the menu, above everything else.

The fixed options are half speed, normal, double, and the highest setting. A tick marks the one in use. Below them sit Play Custom Speed, which shows your current custom multiplier, and Set Custom Speed, which is where you change it.

There is no slider. Several guides describe a speed slider on the toolbar. There is no slider anywhere in this program. Speed is a menu choice, and the toolbar has no control for it.

It changes the timing of your recording. It does not make your computer or your applications any faster.

When you record, the program captures two things. What you did, and how long you waited between actions. Double speed compresses those gaps. Half speed stretches them.

That distinction explains almost every speed problem people run into. Your macro may now click twice as fast. The website still loads at the speed it loads. The dialog still takes as long to open as it always did. Speed compresses your side of the conversation. The other side does not speed up to match.

Choose Set Custom Speed and enter a multiplier.

The dialog prints the range it accepts, so there is nothing to guess at. It runs from normal speed up to the highest fixed option on the menu, and every whole number in between is available.

Confirm it, then choose Play Custom Speed to switch to it. The menu shows your value beside that entry, so you can always see what it is set to without opening the dialog.

The custom option exists because the fixed steps are coarse. Double is often too fast. Normal is often too slow. A modest multiplier between the two usually survives real use.

Because the application on the other end cannot keep up.

At the highest setting, the recorded waiting almost disappears. Every click is sent as fast as the program can send it. Say your macro clicks a menu, then clicks an item inside it. The second click can arrive before the menu has finished drawing. It lands on whatever was underneath.

This is not a bug and it is not something a setting can fix. The macro is doing exactly what it was told, faster than the software it is aiming at can respond.

The highest setting has one honest use: macros that touch nothing external. Keyboard-only sequences, inside one window that is already open. No loading, no network, no animation. For everything else it breaks working macros.

Normal speed for anything you have just recorded. Always test here first.

Double speed once you have watched it work at normal speed and you know where the slow points are.

A custom multiplier for the common middle ground, when double is too aggressive but normal is wasting your time.

Half speed for the awkward cases. Remote desktop, virtual machines, older applications, anything that redraws slowly. It is also the best diagnostic tool here. If a macro fails at normal speed and works at half speed, you have found the cause.

The pattern is simple. Record at your own pace. Test at normal speed. Then raise the speed one step at a time and watch each run. A macro that only ever ran at the highest setting has never really been tested.

These two settings compound each other, and they cause most of the failures blamed on the loop feature.

At high speed with a loop count, each pass begins the instant the last one ends. The application never gets a moment to settle. By the third pass the screen can be somewhere the macro was never designed for.

When a loop misbehaves, lower the speed before you change anything else. Loop behaviour is covered on the TinyTask loops page, including why there is no delay setting between passes.

If a fast macro is already running away from you, press Pause or ScrollLock. The stop playback page covers the cases where that does not seem to work.

Your speed setting is written into the compiled file and cannot be changed afterwards.

The report shown after compiling lists the execution speed under Program attributes. That is the speed the standalone macro will run at, on every machine, every time.

So set the speed before you compile, not after. If it turns out wrong, the only fix is to change the setting and compile again. The whole process is on the compile to EXE page.

A macro that misses its target at every speed does not have a timing problem.

The program replays screen coordinates. A moved window, a new resolution, or different display scaling all send the clicks somewhere else. Speed cannot fix any of that. Scaling catches people moving between a laptop and an external monitor, and it is covered on the Windows 11 page.

The test that separates the two is quick. Run the macro at half speed and watch it. If it is landing in the right places but too early, it is a speed problem. If it is landing in the wrong places, it is a coordinate problem, and the not working page covers those.