how it works

Once per second, the app observes which audio files your DAW is actively working with — the direct signal of an in-progress recording. The most recently modified active take file is the current take.

"Recording" means that file was modified within the last ~4 seconds. That window is deliberate: DAWs flush recordings to disk periodically, not continuously — REAPER, measured, flushes only about every 3.4 seconds — so a tighter window would flicker between flushes. Leaving the recording state is additionally debounced over a few quiet scans.

If that observation yields nothing (permissions, unusual setups), detection falls back to file freshness in the watched folder alone — a weaker signal that can also trigger on the flush a DAW performs when closing a file.

The media folder is auto-detected per DAW (each has its own layout convention; see below), with the common folder of the open takes as ground truth while recording. You can also pin a folder manually in Settings.

REAPER

REAPER is the best case: it stamps a single global $recpass counter — shared by every track of a pass — into each recorded filename, so the take number is read, not derived. Set Preferences → Audio → Recording → "Recorded filenames:" to:

$rectag-$tracknumber-$recpass000

The app's default pattern, ^(?:(.*?)-)?\d+-(\d{3,})\.wav$, mirrors that format with two capture groups: group 1 is the piece name (the $rectag), shown above the take number; group 2 the rec-pass. The name part is optional: a fresh project's $rectag is empty until set, and REAPER then writes name-less files ("01-042.wav") — those still count, just without a piece label. Recording to WAV is assumed by the default pattern.

Custom naming schemes

The pattern is editable in Settings. The rule: the last capture group must land on the $recpass part of your filenames; optionally, group 1 captures a name to display. Patterns that fail to compile — or that backtrack catastrophically — are rejected with an error and the last working pattern stays active. A pattern that captures something non-numeric shows it verbatim (and the "next take" preview is disabled for it, since there's nothing to increment).

Logic Pro, Pro Tools, Nuendo, Cubase, Bitwig Studio, Waveform, Studio Pro

These DAWs have no session-wide counter — they number takes per track in the filenames (Logic: Track #NN in Audio Files/; Pro Tools: Track_NN in Audio Files/, including split-stereo .L/.R pairs; Nuendo and Cubase: Track_NN in Audio/; Bitwig Studio: Track-N in recordings/; Waveform: Edit_Track_Take_N in Recorded/; Studio Pro: collision uniquifiers name(K) in Media/, bare = take 1). The app reads every armed track's latest index and collapses them into one session number.

Pro Tools playlists: if you record playlist-per-take (standard in classical sessions), files are named Track.PP_NN — and the app counts the playlist number PP as the take, not the clip index NN. A false start recorded into the same playlist doesn't advance the count; the playlist number is the take, exactly as an engineer counts it.

Piece names from track naming

When every track of a pass shares a prepended name — WSZY_VOX, MOZART_01 — the app shows that prefix as the piece, the way REAPER's $rectag is shown. The evidence bar is deliberately high, because a wrong piece is worse than none. The prefix must end at a separator (_, -, or space), and then one of two proofs must hold: either some track demonstrably survived a renaming — the same track name under a different prefix (or bare) at a different time — or the structure alone is strong: four or more tracks sharing the prefix, with substantial names after it. The time test is how section numbering and mic pairs stay out ("Violin 1" and "Cello 1" record in the same passes; two pieces never overlap in time), and purely numbered tracks (MOZART_01…15) always require the rename proof — so a first piece with numbered tracks shows the project name until the second piece exists. Tracks split across drives count as one pass. Known trade: four mics all named "Piano ⟨position⟩" recorded alone read as piece "Piano". Naming history is read from the media folder, so it survives wherever the DAW's edit cursor wanders.

The derivation is a heuristic — honestly

There is no universally correct collapse rule, so Settings offers two:

• Most common (default) — the mode of the per-track indices, ties broken upward. Survives one track running ahead because a take was discarded; can read low right after new tracks are added mid-session.
• Highest — the maximum. Correct when tracks are only ever added late; a single track that ran ahead inflates the number.

If your displayed number looks off by one after deleting takes or adding tracks, this is why — switch the rule to match your workflow.

Ableton Live

Live's filename numbers repeat and skip across passes, so they are not trusted at all. Instead the app counts recordings: every armed track writes exactly one file per pass into Samples/Recorded/, so a track's file count is its take count, collapsed with the same rule as above. (Timestamp clustering was tried and rejected: it merged rapid takes — a real 19-pass session read as 8.)

Ardour, Harrison Mixbus

Ardour (and Mixbus, which shares its recording engine) records Track-N files into interchange/<session>/audiofiles/, where N is a per-track counter — the take, collapsed with the same rule as the other per-track DAWs. Stereo tracks record as two mono files (%L/%R); both halves count once.

The Session Properties naming options are understood in every combination. With "Prefix take name" enabled (the default in new sessions), each pass records under a fresh take name, so the trailing counter stays at 1 — the app reads the take from the take name's number instead (Take3_… = take 3), which Ardour advances at every stop. A "Prefix track number" is recognized as a track number, not a take. One edge to know about: a track name whose first underscore-segment ends in digits (Room2_Mic) is indistinguishable from a take-name prefix and can misread — rename the track or let the collapse rule absorb it.

LUNA

LUNA names its recorded files with opaque UUIDs, so filenames carry nothing — but every audio file gets a small metadata sidecar identifying its track and marking it as a recording (as opposed to an import or a bounce). The app counts recorded files per track from those sidecars — so track renames can't split a track's history and non-recorded audio never pollutes the count — and collapses the counts with the same rule as the other per-track DAWs. Like Ableton Live, every pass counts: LUNA discards nothing, so a false start becomes its own take.

disk space & remaining time

The window's small bold lines show free space on every drive being recorded to and an estimate of the recording time each buys — one line per volume, led by the volume's name (recording different tracks to different drives, Pro Tools-style, gets one line and one independent estimate per drive). The estimate is measured, not assumed: the app watches how fast the current session's take files actually grow (a sliding window over the last ~40 seconds of writes), so it reflects your real track count, bit depth, and sample rate. Free space is the same purgeable-aware figure Finder shows.

The compromises, honestly:

• The estimate needs data — it appears about ten seconds into the first recorded pass and remembers the rate between takes.
• It assumes the future resembles the recent past. Arm fewer tracks and the runway lengthens; add tracks and it shortens — the display adjusts smoothly over the next takes rather than jumping.
• Above two hours the display deliberately rounds down to whole hours ("over 9 h"). At that range the measurement noise spans tens of minutes, and quarter-hour precision would be false confidence. Below two hours — when the number starts driving decisions — it becomes precise to five minutes, then to the minute.
• It is an estimate, not a promise: other software eats disk too, and macOS reclaims purgeable space on its own schedule. Treat the last half hour as already gone.

Settings → Display turns the line off if you'd rather not know.

gotchas — the honest list

• The number is inferred from filenames. If your recording filenames don't embed take information, the app cannot work. Some DAWs record into a single self-contained document with no take files at all — Reason is the known case (assessed against a live session) — and those can't be supported; running such an instrument as a plugin inside a supported host works, since the host records the takes.
• The "stopped" indication lags a take's actual end by a few seconds — that's the debounce that keeps the indicator from flickering between disk flushes. Recording shows immediately; stopping settles.
• Detection runs once a second, so everything can be up to a second behind.
• The DAW must run on the same Mac and user account — the app works by observing open files. It cannot watch another machine.
• Only common audio extensions are recognized (wav, aif/aiff, caf, w64 where the DAW writes them). REAPER's default pattern assumes WAV.
• If the media folder lives under Desktop, Documents, or Downloads, macOS may ask for folder access once — normal, and required.
• Take files on stale network mounts can stall the filesystem itself; the app guards against this, but detection may stutter for a few seconds when a mount misbehaves.
• Steinberg apps version their process names ("Nuendo 13"); the app matches by prefix and ignores their helper processes. A future renaming scheme could require an app update.
• The per-track derivation ambiguity described above is inherent, not a bug to be fixed.

remote display

Enable it in Settings → Remote Display, then open http://<your-mac>.local:8787 on any phone, tablet, or laptop on the same network (raw IP fallback URLs are shown in Settings). The first connection may prompt macOS to allow incoming connections — click Allow.

The page offers two per-device toggles, remembered per device: paper / poster style, and card (muted, centered) / full (edge-to-edge, readable across the room). While recording, poster floods red — an on-air light. The page polls a few times a second and dims when it loses the app; it never shows stale data as fresh.

Stopping the screen from sleeping. Set the device's Auto-Lock: Never (iOS: Settings → Display & Brightness; Android: Settings → Display → Screen timeout) and keep it on power. On a phone or tablet that is the only reliable answer, and it's worth knowing why: the web's Screen Wake Lock API — the one mechanism that can hold a screen on — is only offered in a secure (HTTPS) context, and this display is served over plain HTTP on your own network, so those browsers don't expose it at all. Where it does exist (the display opened on the Mac itself at http://localhost:8787) the page takes it automatically, with no setting to find. Add ?diag=1 to the address if you ever want to see which of those applies. For a permanent stand display, Guided Access is worth turning on as well — it stops a curious visitor swiping away from the take number.

One thing we tried and dropped, for the record: looping a silent video, the long-standing trick for keeping iOS awake. We couldn't make it hold a current iPad — the video was playing and the screen dimmed and locked regardless — so it isn't in the app. Even if it could be coaxed into working, a display that must not fail mid-session shouldn't rest on whether iOS decides to keep an invisible video playing; the device's own Auto-Lock setting is the dependable answer.

Anyone on your network can view this page and the API below while the remote display is enabled. It serves the take number and project/piece names, nothing else — but in a facility with untrusted network users, leave it off.

API

With the remote display enabled, a versioned JSON endpoint serves everything the displays show — for tally lights, OBS overlays, Stream Decks, or whatever your studio needs:

curl http://<your-mac>.local:8787/api/v1/state

{
  "api": 1,
  "app": "Take Counter",
  "appVersion": "1.0",
  "daw": "REAPER",
  "hasTake": true,
  "piece": "rapsodia",
  "project": "2026-08-03-jastrzebie-wajnberg",
  "recording": true,
  "status": "Recording",
  "take": "243",
  "takeNumber": 243,
  "updatedAt": "2026-08-09T18:12:03Z"
}

GET only, no authentication (it's your LAN; see the note above), CORS Access-Control-Allow-Origin: * so browser dashboards on other machines can fetch it directly. Poll at 1–2 Hz; faster gains nothing since the app itself updates once a second.

trial & licensing — what actually happens

The app is fully functional for 7 days, quietly. For the next 21 days it shows a dismissable reminder at launch (the dismiss button enables after 30 seconds). After that, the take display locks until a license is entered; the app keeps running and detection keeps working, but the number is withheld.

A license is a small signed text file. The app verifies it offline with a public key — there is no activation server, no phone-home, nothing to reach. It works on air-gapped machines: paste the license text into Settings, or drop the file at ~/takecounter.license (a studio manager with a thumbdrive is a fully supported installation method). One license covers all your machines. The licensee's name is shown in the window — that's the whole anti-sharing mechanism.

What the app stores locally

• Your preferences, in the standard macOS defaults system.
• The installed license file, at ~/Library/Application Support/TakeCounter/takecounter.license.
• A first-launch date for the trial clock — in preferences and in a small hidden file in ~/Library/Application Support with a machine-derived name, so resetting preferences alone doesn't restart the trial. We'd rather tell you it exists than pretend otherwise: the cryptography protects the license; the trial clock is a social contract.

Nothing is ever transmitted anywhere. See privacy for the complete statement.

diagnostics

Settings → Diagnostics → Copy Diagnostics Info puts a plain-text report on your clipboard: app and macOS versions, detected DAW, folder, regex status, license phase, and the newest take filenames with what the active pattern captured from each. It is only ever copied — nothing is sent — and it exists so a bug report can be a paste instead of a memory test. Please include it when reporting problems.