Dictation

Hold a key, talk, let go. The words appear where your cursor already is — in your email, your editor, your case-management system. LymeScribe doesn't need to be the app you're looking at.

Last updated 2026-08-31

The hotkey is the whole product

Dictation is push-to-talk: hold the key while you speak, release when you're done. Release is what submits the audio — there's no stop button to find, and no dead air at the end of every clip.

macOSOption + Space by default. Settings also offers a double-tap-a-modifier trigger if you'd rather not hold a two-key chord, plus one-click presets for Control + Space.

WindowsAlt + Space by default.

LinuxAlt + Space by default on X11. On Wayland the desktop has the final say — see the callout below.

To change it, open Settings ▸ Hotkeys, click the Push-to-talk key field, and press the combination you want. Esc cancels without changing anything.

Two optional hotkeys live on the same pane, both unset out of the box:

Toggle recording key — press once to start, again to stop, instead of holding. Useful for long dictation, or if holding a chord is uncomfortable. Clear the field to disable it.
Re-insert last transcription key — types your most recent transcription wherever your cursor is now. The rescue key for when you dictated into the wrong window.

What you see while you talk

A small overlay appears on screen while dictation is running and walks through its states in order: Starting microphone, then Recording with a live waveform so you can see the mic is actually hearing you, then Transcribing, then a completion line with how long it took. If something goes wrong it says so there rather than failing silently — for instance, if a paste is blocked it tells you the text is on your clipboard and to press paste yourself.

Linux The overlay has two structural limits on Wayland. It isn't truly click-through: clicking on it is absorbed rather than passed to the window behind, because the UI toolkit exposes no way to define an input-transparent region. And its position is best-effort — a Wayland client can't place its own window, so the compositor decides where it lands. On X11 both are precise, matching Mac and Windows.

The Dictate card

The main window's capture band has a Dictate card with a Record button. Unlike the hotkey, this one is a toggle: click to start, click again to stop — the button becomes Stop with a running timer while it's recording.

Because you're looking at LymeScribe rather than at the app you want the text in, the card's text lands on your clipboard when you stop, and the card says so. The hotkey is the one that types into whatever app you're actually in. The card exists for the case where you want a quick note without leaving the app, and as the discoverable version of the feature for people who haven't set up a shortcut yet.

Linux On some desktops the card, or the tray, is the only way to record. Wayland has no direct key-grab API — global shortcuts go through a desktop portal, and the desktop owns the chord rather than the app. That works on GNOME 48+, KDE Plasma 5.27+, Hyprland, and any X11 session. On GNOME 47 and earlier the shell never signals key release, so hold-to-talk genuinely cannot work; on sway, river and other wlroots compositors the portal has never implemented global shortcuts at all. On those desktops the honest fallback is toggle-from-tray: press Record in the tray menu or in the window. Where the portal is available, the app can only ask for a preferred chord as a hint — the desktop may grant a different one, or ask you to bind it in the desktop's own keyboard settings — which is why there is no chord picker in Settings on Wayland, only the desktop's own description of what it gave you.

How the text reaches you

When transcription finishes, LymeScribe has to get the text into your app. There are three ways, chosen in Settings ▸ Dictation ▸ Text delivery:

Type it into the appLymeScribe types the text wherever your cursor is. Your clipboard stays exactly as you left it. This is the default on new installs.

Paste it (replaces your clipboard)Fastest for long dictation — but whatever you had copied is gone.

Just copy it to the clipboardNothing is typed or pasted. The text waits on your clipboard until you paste it yourself.

Two toggles sit alongside:

Never modify my clipboard — a guarantee rather than a preference. With it on, LymeScribe types instead of pasting and will never replace what you've copied.
Also leave a copy on the clipboard — belt and braces: type it and keep a copy you can paste again.

Why typing is the default. Pasting is faster for a long paragraph, but it costs you whatever was on your clipboard — and people copy things they need. Typing is slower on very long dictation and slightly fussier in apps with aggressive autocomplete, which is exactly why the choice is yours.

macOS Typing needs Accessibility permission; pasting needs Automation. Without Accessibility, LymeScribe does not type — it says so rather than falling back to something you didn't ask for. Paste delivery additionally uses Automation (System Events) to press Command-V on your behalf; decline that and the text is copied for you to paste yourself. Both are in Settings ▸ Permissions and can be granted later.

Per-app overrides

Some apps behave badly with one delivery method and fine with another — a terminal that mangles simulated keystrokes, an editor that swallows a paste. Settings ▸ Dictation ▸ Per-app overrides lets you pin a different method for named apps.

Add one by typing the application name — on Windows that's the process name, such as WINWORD; on Mac it's the app name, such as Terminal — picking a method, and pressing Add. Each row has a Remove button. Everything not listed uses your global default.

Linux Per-app overrides can be edited on Wayland but won't apply. Knowing which application currently has focus is private to the desktop under Wayland — a deliberate security boundary, not a gap to work around. So on a Wayland session the app can't tell which app you're in, and every app gets the global default method. The Dictation pane says so on the machines where it's true. On X11 the focused window is visible and overrides work normally.

Linux Typing into other apps on Wayland is a permission, not a capability. Wayland deliberately has no equivalent of the X11 mechanism LymeScribe uses to type; it goes through the desktop's remote-desktop portal instead, and that needs your consent through a system dialog. Until you grant it, dictated text goes to your clipboard, the overlay says so, and you get exactly one desktop notification per session — not one per dictation. Settings shows an Allow LymeScribe to type button that triggers the desktop's own permission dialog, so its wording is the desktop's, not ours. The grant is meant to be remembered across launches. On desktops with no remote-desktop portal at all (sway, river and other wlroots compositors) no Allow button is shown, because pressing one couldn't help — Settings says plainly that this desktop doesn't offer the permission and suggests an X11 session. Dictation still works there, degraded to the clipboard.

Some people bridge that gap with ydotool, which injects input below the compositor. LymeScribe does not use or support it: it needs privileges over your whole machine's input that LymeScribe deliberately does not ask for. If you want typing with no extra setup, an X11 session gives it.

Speaker labels are never applied to dictation

Speaker labels are a batch feature. Dictation is one person talking into their own microphone, and it runs in real time where the extra pass would cost latency for no information. Labels are produced only for files you transcribe as a batch job — see Transcribing files and Naming speakers.

Fixing words it gets wrong

If a name, product or piece of jargon comes out wrong every time, the corrections dictionary fixes it permanently and automatically after each transcription, dictation included. It's covered at the end of Naming speakers.

If it isn't working

The overlay never appears. The hotkey isn't reaching the app. On Mac, check Accessibility permission. On Linux Wayland, check whether your desktop granted the shortcut at all — Settings shows the desktop's own description of the chord it gave you.
The overlay appears but the waveform is flat. Wrong microphone. Change it in Settings ▸ Dictation.
Text lands on the clipboard when you expected typing. That's the documented fallback path — the overlay will have told you why. On Mac it's usually Accessibility; on Linux Wayland it's usually the typing permission.
Nothing transcribes at all. Check the status strip at the bottom of the main window — it's the single home for machine facts, including whether your server is reachable and what the engine is doing.