Preparing the Show Machine `[All]`
CueSync's timing budgets assume it gets the CPU when it asks for it. On a machine that is busy doing something else, the operating system can hold any application — CueSync included — off the processor for tens of milliseconds at a time. That is longer than the entire beat-to-decision budget, and it is the one source of late cues that no amount of work inside the app can fix.
This page is the setup that protects it. Fifteen minutes before a show beats any setting in the interface.
Why this matters more than it sounds
CueSync's own decision path is fast with enormous margin — a cue decision uses well under 1 % of its budget, and the Show Editor's timeline draws in a fraction of a frame. Measured on a deliberately busy machine, though, the same code occasionally took six times its budget, and the cause was never CueSync: it was the machine pausing every process to service something else.
So the picture to hold is:
| Effect on cue timing | |
|---|---|
| What CueSync does per beat | Tiny, and heavily engineered to stay that way |
| What you do in the interface | None — the engine runs off the interface entirely |
| What else the machine is doing | The dominant risk, by a wide margin |
Nothing below is exotic. It is the same discipline you would apply to an audio workstation.
Before the show
Give CueSync the machine
- Quit everything you are not using. Browsers are the worst offender — a single tab running video or a busy web app can keep several cores warm for the whole show.
- Pause file sync. Dropbox, iCloud Drive, OneDrive and Google Drive all scan and upload in bursts. Quit them, don't just close the window.
- Pause backups. macOS Time Machine and Windows File History both kick off on their own schedule, and a backup that starts mid-set is a long, heavy disk and CPU load.
- Disable antivirus real-time scanning for your show folder, or exclude it. On Windows this is the single most common cause of unexplained stutter.
- Let indexing finish, or turn it off. macOS Spotlight and Windows Search index new files aggressively — copying a track library an hour before doors means indexing during your show.
Keep it awake and at full speed
- macOS — set Energy Saver / Battery so the display and machine never sleep on power. CueSync already prevents system sleep while a show is running, but a machine that has throttled down for battery does not clock back up instantly.
- Windows — set the power plan to High performance (or Best performance on the slider). Balanced parks cores and downclocks, which shows up as jitter.
- Stay on mains power. On battery, both platforms trade clock speed for runtime.
- Turn on Do Not Disturb / Focus. A notification banner is a compositor event, and a full-screen update prompt is worse.
Stop the machine from changing under you
- Disable automatic OS updates for the run of the show, and reboot before doors rather than discovering a pending update at the worst moment.
- Reboot before the show. It is the cheapest way to clear whatever accumulated since the last one.
- Don't change the audio device mid-show if you are using local audio playback.
Network
- Prefer wired. See Devices and Network Outputs for the show-network layout.
- Keep the show network off the internet where you can. Broadcast chatter and background updates share the same interface as your Pro DJ Link and lighting traffic.
- Turn off Wi-Fi if you are wired, so the machine cannot quietly switch routes.
Hardware
The minimum requirements are what the app needs to run. For a machine that will drive a show, aim higher:
| For running shows | |
|---|---|
| RAM | 8 GB or more. CueSync's runtime is allowed up to 2 GB, and the deck waveform cache alone can hold a few hundred megabytes on a large multi-deck rig. On a 4 GB machine that leaves the operating system competing with you, and memory pressure surfaces as interface lag. |
| Storage | SSD. Track analysis and show loading are both disk-bound. |
| CPU | Any modern multi-core machine is fine. Core count matters less than the cores being free — see above. |
| Display | A second screen is optional; see Multi-Monitor. |
Verifying it worked
Rehearse under show conditions. The only test that means anything is running the real show, on the real machine, with everything that will be running on the night already running. A machine that is clean in that rehearsal is a machine you can trust; a machine tested while idle tells you nothing about the night.
Check the notification history afterwards — View menu → Notification History
(Cmd+Shift+H / Ctrl+Shift+H). CueSync watches its own beat-processing time and records a
"Beat pipeline degraded — trigger timing may jitter" entry when it starts overrunning. This is
recorded quietly rather than shown on screen, so it will not interrupt you mid-show — which also
means you have to go and look. Do that after every rehearsal. If the entry is there, the machine
was stalling the app, and this page is the fix list.
If your installation was set up with diagnostics mode enabled, the Diagnostics screen shows the same information live, with median and worst-case figures. It is a launch flag rather than a setting, so check with whoever set up your install — if you do not have it, the notification history above covers the same ground.
Related
- Installation — install, activate, first launch
- Diagnostics — live latency and health
- Troubleshooting — when something is already wrong
- Technical Specifications — the timing budgets themselves
Looking for a quick fix?
The Help Center has short task-focused articles and a support team that responds within 24 hours.