Screen Recorder (record, edit and share your screen) (part 3)

What it is

This is part 3 of the Screen Recorder (record, edit and share your screen) page. It carries presets and templates, auto-titling, and what is deliberately deferred, moved here because a single page is capped at 40,000 characters.

A saved preset outranks every default, so setting your defaults once and saving a preset gives you two different things: a starting point and an override. Below is how presets and templates compose with Quick Capture, how a take gets its title, and what is explicitly not built yet.

Where to find it

The recorder itself, its hotkeys and its library are on part 1. What is here is the setup you can reuse and the details that decide how a take is named.

How it behaves

Presets & Templates + Quick Capture

Two distinct saved-scene concepts, both built on the recorder's canonical LayoutDocument:

• Preset — a layout WITH everything bound: the exact sources (which screen / window / camera), their positions, scales, crop/fit, shape, and the audio devices. "Record with this preset" reproduces that exact scene with no setup, the same sources every time. A preset is essentially a saved LayoutDocument + a name (src/shared/screen-recorder/screen-capture-preset.ts: extractPreset, presetStartTarget). Persisted as screenCapturePresets[]; the starred one is defaultScreenCapturePresetId.
• Template — a source-less layout skeleton: the same geometry / roles / crop / shape, but with the sources stripped to empty slots (src/shared/screen-recorder/screen-capture-template.ts: extractTemplate, templateSlots, bindTemplate). Applying a template asks you to pick a source for each slot, then bindTemplate drops them into the saved geometry to produce a record-ready layout. Persisted as screenCaptureTemplates[].

In the Clip composer (src/renderer/src/features/screen-recorder/clip/ClipPresetTemplateBar.tsx): Save as preset / Save as template (inline name field — no browser prompt). Each preset row offers Record (records the bound scene immediately), Load (loads it into the composer to tweak), a ★ default toggle, and delete. Each template row offers Apply — which opens the per-slot source picker (src/renderer/src/features/screen-recorder/clip/TemplateApplyPanel.tsx) — and delete. Saving your first preset makes it the default automatically.

Quick Capture is zero-click: it records the default preset's exact scene. With no default preset set it falls back to the built-in default — a PiP of the last-used source when it's still available (else the primary monitor) + the remembered webcam (only when one is set) + the remembered mic — so it works before any preset is saved (no "record once manually first" requirement). The pure decision (pickPrimaryMonitorSource + resolveQuickCapturePlan) lives in src/shared/screen-recorder/quick-capture.ts; screenRecorderService.quickStart() does the IO (enumerate screen sources, read the primary display, pre-flight that the planned source is still connected, call start). Failures push SCREEN_RECORDER_QUICK_START_FAILED so hotkey/tray callers are never silent.

Triggers (all gated on screenRecorderEnabled): the Start Recording system-tray entry, the Fastpath global hotkey (screenRecorderQuickRecordHotkey, default Ctrl/Cmd+Alt+R), and the screen-recorder:quick-start IPC channel / CLI capture route.

Start speed + cues (updated 2026-09-02). Once Screen Recording is enabled, Omniscio keeps the recorder engine, the configured countdown, and a fresh hidden control HUD loaded in memory. The countdown is prepared again immediately after every use, and changing its duration prepares the new version before the next hotkey press. Quick Record never waits for background warm-up work: monitor capture can reuse a topology-checked screen list, while window capture uses a bounded fresh check so a closed window is never recorded by mistake. Disabled users do not pay the startup or idle-memory cost. None of the resident surfaces holds a desktop, microphone, or camera stream while idle. The countdown includes None (start instantly); a "Play a sound when recording starts" toggle (on by default) provides an audible cue. With system-audio capture on, that chime can be faintly re-recorded at the start.

When recording actually begins (updated 2026-09-29). Opening the microphone/camera and spinning up the desktop capturer is a cold-start cost after the hotkey — measured 2.6–5.9 s on the development box, on top of roughly 1.4 s to reach the capture host. For that stretch nothing is being recorded, so the HUD says "Starting…" with no live REC dot and no running clock, and only swaps to the red dot + timer when the host reports its first real frame. The elapsed timer therefore starts where the video starts: the timer you watch and the length of the file you get now agree. The start chime rings at that same moment (once per take), so it means "you are on camera now" rather than "the take exists".

The start has two phases, and nothing records until the hardware is confirmed. The hotkey opens the microphone, camera and screen and holds them; the recorder is not built and not started until that moment. When the devices that opened are the ones you chose, the take runs its pre-record countdown (when one is set) and begins the instant that count reaches zero. When one of them is not — a device that is unplugged, held by another app, or whose stored id has gone stale — Omniscio does not quietly record with a different one. It asks: "Nothing has been recorded yet. One of your devices did not open", naming the device that did open, with Record anyway and Don't record. Declining (or not answering within 30 seconds) leaves nothing — no take, no entry in the library, no partial file — because a take that never recorded a byte should not appear among your recordings. A missing system-sound capture is not asked about: that is a platform limitation rather than a substitution, so it warns and carries on.

The countdown is the last thing that happens before you are captured (updated 2026-09-30). The 3-2-1 does not start until the microphone, camera and screen are open and held — it runs on the far side of the capture command, not before it, so the number it shows is one it can keep: when it reaches zero, the recording begins. That is also why the count comes after the "Starting…" warm-up rather than in front of it, and why Quick Record's first few seconds are the warm-up alone. Answering the device question above counts as the run-in, so the countdown plays after your answer. With the countdown on None, the recording begins the moment the hardware is confirmed.

Your devices are checked against what is actually connected. A saved microphone or camera id is a per-profile handle, not a permanent hardware name: it changes when the app's profile does (a data-directory move), and never comes back. A stored id that is no longer present is never requested, so a dead id costs nothing instead of two failed attempts and a retry delay on the start path. If your chosen device turns out to be gone, Omniscio falls back to the system default, names the device it actually used, and logs the real reason — including the failure's name and the constraint it refused, which is empty in the raw browser error. This is the path every UI entry point takes — Quick Record, the Record composer and the picker all send a composed layout.

The exception, so the promise above is not read as universal: a direct SCREEN_RECORDER_START with no layout takes the older single-source host path, which still asks for the stored device id exactly and, if it cannot open, fails the take with an error rather than substituting a device or falling back. It never records with hardware you did not choose — which is the property that matters — but it does not get the rescue, the device check, or the naming above.

Nothing else presents the take as recording over that window either: the library's list row shows no status chip until capture is live (it used to paint a red "recording" chip immediately), Pause is not offered — there is nothing captured to hold, so the main process refuses the request and the button is hidden — the system-tray menu offers "Cancel Recording", never "Stop Recording" (it read status alone until 2026-10-04, so it claimed a live capture for the whole warm-up; the honest flag is captureLive, and stop() over that window cancels the start, which is what the row does) — and the webcam self-view is revealed on that same first-frame edge, not when the take is created, so it is never on screen before the camera behind it is open. Finish and Discard remain, and are the ways out of a warm-up that is taking too long — and over the warm-up that first button reads Cancel, because that is what pressing it does (nothing has been captured to finalize); it turns into Finish on the first-frame edge, alongside its Finish & share sibling. If you want a run-in before you are captured, set a countdown: it plays once the hardware is ready, so its last beat is the moment recording starts. With the countdown on None there is no 3-2-1, and the HUD's "Starting…" is the only cue that the warm-up is still running.

Auto-titling

On by default. After a recording finishes, Omniscio transcribes it locally (Whisper) in the background, then generates a short AI title from the transcript via Claude Haiku and saves it to ai_title. The title shows as the recording's name in the library, the review window, and the public share page — but ONLY when you haven't named the recording yourself (a manual source_label always wins). Turn it off with Auto-title recordings in the Screen Recording settings (screenRecorderAutoTitleEnabled, default on). It is fail-soft (a failure just leaves the recording showing its capture-time fallback — it never affects the recording or captions), credential-gated (no API key → skipped), daily-cost-capped, and PII-scrubbed before the transcript reaches the model, and it never overwrites an existing title. The manual Summarize action still produces the fuller ai_tldr + ai_chapters_json.

A wordless recording is skipped, not titled. Whisper never returns an empty transcript for a capture with no speech — it narrates the audio instead ("(upbeat music)", [BLANK_AUDIO], ♪-wrapped lyrics). Titling from those spends a real call to describe the SOUNDTRACK rather than the recording, so hasSpeech() strips the bracketed / ♪-wrapped markers and requires a letter or digit to survive; no speech → no title, and the card keeps its capture-time label. Speech that merely mentions music is unaffected (the marker is stripped, the narration around it still counts).

Two guards that look redundant and are not (auto-title-service.ts): the source_label check means "a HUMAN named this", and the ai_title check means "already auto-titled". Collapsing them, or feeding either a placeholder, re-breaks the feature silently — auto-title fails by doing nothing, so nothing surfaces. Pinned by tests/unit/services/screen-recorder/auto-title-gate.test.ts.

Not yet (deferred)

Recording / Project shared:

• Auto TL;DR + chapters on finish — only the AI title auto-generates after a recording (see Auto-titling); ai_tldr / ai_chapters_json still come only from the manual Summarize action.
• Cross-lane chip drag gesture (lane moves use the Forward/Back buttons — the vendored ChipTrack primitive needs an upstream change for drag-across-lane).
• Audio waveform lane, and canvas background/padding presets.

Projects-specific:

• Multi-asset bake — export of projects with multiple video sources or image-asset compositions (single-source only today).
• Projects card share/copy-link parity — library cards for projects currently don't show a quick-share icon like recording cards do; parity pending.

Related

• Screen Recorder (record, edit and share your screen) — part 1 of this page, with the surfaces and the user-facing behaviour.