Where the loop settings are
Click Prefs, the wrench at the right of the toolbar. Two entries control repetition.
Set Playback Loops takes a number. The macro runs that many times and stops.
Continuous Playback takes no number. The macro runs until you stop it yourself.
There is a small detail in that menu worth pointing out. The current loop count is printed in brackets next to Set Playback Loops. You do not have to open anything to see what it is set to. Glance at the menu and it is there.
Setting a loop count
Choose Set Playback Loops. A small box appears asking for the number of playback loops.
Type your number and confirm. Then press Play as normal. The macro runs, returns to its starting state, and runs again, until the count is used up.
The count applies to every playback from then on. It is a setting, not a one-off instruction. If you set it high for one job and forget, the next macro you play will repeat too. Checking the number in brackets before you press play takes a second and saves confusion.
Your setting is written to the settings file that sits beside the program, along with everything else you change in Prefs. That is covered on the settings file page.
Continuous playback
Continuous Playback repeats the macro with no end.
This is the right choice when you do not know in advance how many passes you need. Watching a queue drain, waiting for a screen to change, holding a session awake. You start it, and you stop it when the job is done.
It is the wrong choice while you are still building the macro. A macro with a mistake in it will repeat that mistake forever, and every pass leaves the screen further from where it started. Use a small count while testing.
To end a continuous macro, press Pause or ScrollLock. Those keys are always active and they do not need the window in focus. If it will not stop, the stop playback page covers every case, including keyboards with no Pause key.
Watching which pass it is on
The title bar tells you, while the macro runs.
During playback it shows the elapsed time and then, in brackets, the current pass against the total. So a macro on its second pass of five reads as two of five, and a single run reads as one of one.
This is the easiest way to confirm a loop count actually took effect. Set the count, press Play, and read the bracket. If it says one of one, the setting did not apply and you are watching a single run.
There is no delay between loops
The program does not have a wait setting. One pass ends and the next begins immediately.
For most macros that is fine. For some it is the whole problem. If your macro clicks a button that takes a moment to respond, the next pass starts before the screen has caught up, and the second run clicks into empty space.
There is one way to fix this, and it is not a setting. Record the wait into the macro itself. At the end of your recording, before you press the record hotkey to stop, sit still for as long as the gap needs to be. The program records that idle time. On playback it reproduces it, so every pass ends with your pause built in.
It feels crude. It works, and it is the only method that actually exists here.
Speed changes what a loop does
TinyTask loops and playback speed are separate settings. They multiply each other's problems.
A macro that works once at normal speed can fail on the second pass at high speed, because the application never gets a moment to settle. If a loop is behaving oddly, drop the speed before you touch anything else. The playback speed page explains what each speed option really does.
The safe order when testing is fixed. Normal speed, loop count of two, and watch both passes. Only then raise either number.
What breaks on the second pass
A macro that runs perfectly once and then goes wrong is the most common loop complaint, and the cause is almost never the loop setting.
The screen is not where it was. The program replays screen positions, not buttons. If the first pass opened a window, moved something, or scrolled a list, the second pass is aiming at coordinates that no longer hold what they held before.
Something only happens once. A confirmation dialog that appears the first time and not the second. A login that is already done. A field that is already filled. The macro still clicks where that thing used to be.
The application got slower. Second and third passes often run against an application that is now doing more work, so it responds later than it did on the first pass.
The fix is usually to make the macro end where it began. If the last action returns the screen to the exact state the first action expects, the loop becomes reliable. Recording a final click back onto the starting window is often all it takes. The wider set of failures is covered on the not working page.
Loops in a compiled macro
Your loop count is written into the compiled file, permanently.
When you press the .exe button, the program shows a report of what it built. Under Program attributes it lists the repeat loops it wrote into that file. Whatever the count was at that moment is what the standalone macro will do, on any machine, every time.
Pause on that before you send a compiled macro to anyone. A loop count you set for your own testing has just become their behaviour too. Read the report before you hand the file over. The whole process is on the compile to EXE page.
There is no way to change the count inside a compiled file. Change the setting and compile again.
Frequently asked questions
Open Prefs, choose Set Playback Loops, and enter the number of times you want it to run. Press Play as normal. For endless repetition, choose Continuous Playback instead.
Open Prefs and look at the number in brackets beside Set Playback Loops. It shows the value currently in use.
Press Pause or ScrollLock. One press ends it, whether it is on a count or running continuously.
Not with a setting, because the program has none. Record the pause into the end of the macro by staying still before you stop recording. That idle time is reproduced on every pass.
The dialog does not state one, unlike the custom speed box which prints its accepted range. We have not tested the ceiling, so we are not publishing a number that other sites have simply invented.
Because the screen has changed. The program aims at coordinates, so anything the first pass moved, opened or scrolled will throw off the pass that follows. Making the macro finish where it started usually fixes it.
No. Loops control how many times it runs. Speed controls how fast each run goes, and it is a separate setting on the playback speed page. Recording and playback basics are in the how to use TinyTask guide.