Recording a meeting

The Obsidian plugin puts a mic ribbon icon in the left sidebar. Click it to start, click it again to stop. While a recording is running the icon turns into a red record dot, and hovering it swaps in a stop square so it’s obvious what the next click does.

The same three actions sit in the command palette: Oris: Start recording, Oris: Stop recording, and Oris: Toggle recording. Assign a keyboard shortcut to any of them under Settings → Hotkeys → search “oris”. Oris ships with no default chord, on the grounds that whatever you have already bound is more important than whatever we would have picked.

Recording starts where your cursor is, in the note you have open, so the transcript comes back to the spot you were writing in. See recording into a note you have open for what that means if you move around afterwards.

The Oris app has its own Start recording / Stop strip too, so Obsidian doesn’t have to be open (or installed) to capture a meeting. It’s the same single recording underneath: start in either place, stop in either place. See recording from the Oris app.

Pro · coming Two things about this are coming to Oris Pro: Oris noticing that a meeting has started and offering to record it, and the transcript building while the conversation happens rather than after you stop.

From the Oris app

Obsidian is the richest way to use Oris, but it is no longer the only way to start a meeting. The Oris app has its own record strip, sitting above the tabs so it’s visible wherever you are in the app. Click Start recording and the meeting is being captured, exactly as if you’d clicked the ribbon icon in Obsidian. Nothing else needs to be installed or open: on a Mac with no Obsidian at all, this strip plus a Markdown-folder or Apple Notes destination is the complete workflow.

While idle, the strip shows where your next recording will land — the destination you chose during onboarding — and warns you before you record if that destination has a problem (a vault or folder that moved, say), rather than after a meeting has nowhere to go.

During and after the meeting

Once recording, the strip shows a red dot and the elapsed time, with a Stop button. After you stop, it walks through the same stages the Obsidian status pill shows: transcribing, summarizing, and preparing or downloading a model when one is needed. It ends at “Notes ready” with an Open note button that takes you straight to the finished note: in Obsidian for a vault note, in your default Markdown editor for a folder note, or in Notes for an Apple Notes delivery.

A finished run never takes the record button’s place. At “Notes ready” the message and its Open note button sit beside Start recording rather than in place of it, and a run that failed puts its message there the same way, so either way the next meeting is one click away and starting it clears the finished one. While a recording or its transcription is actually running, the strip shows that instead, since there is only ever one recording at a time. The ✕ is still there for when you want to clear the message without recording again, which also brings the destination line back.

Unlike the plugin flow, there’s no cursor and no open note here, so nothing is inserted anywhere while you record. The note is created when the recording finishes, named and placed by your destination’s settings; see Obsidian and Markdown for how that’s decided. In an Obsidian vault, standalone recordings land as new notes in your inbox folder.

If the summary fails on one of these recordings, everything you’d expect still works, and it works from the app: the transcript lands, the ⚠️ block goes where the summary would have, and the retry in Recordings → See all recordings… heals it, patching the note in place on a file destination or delivering the fresh summary as its own note beside the original on Apple Notes. See when a summary fails.

One recording, every surface

There is only ever one recording at a time, and every surface sees the same one. A meeting you started in Obsidian shows up in the app’s strip and can be stopped there, and a meeting you started in the app shows in Obsidian’s status bar the same way. The strip is a window onto the recording, not a separate recorder.

If you try to quit Oris while a recording is running, it asks first. The recorder is a separate process and keeps capturing if the app closes, and the dialog says exactly that, offering Stop recording or Keep recording.

From the command line

The same flow works from a terminal for repo installs: oris-record-start with no target starts a standalone recording, and on oris-record-stop the transcript is processed in the background and delivered to your destination, with a notification naming the created note. The old behavior of printing the transcript to the terminal and waiting for it is still there behind an explicit --stdout flag on oris-record-stop, for scripts that were built on it.

Watching it work

While a recording is active, the plugin shows ● recording 02:14 in Obsidian’s bottom-right status bar. Click it to stop. The pill re-checks every second that the recording is genuinely still running, so it can’t sit there showing a recording that has already stopped.

After you stop, the pill keeps you posted through the work that happens next. It shows ✎ transcribing… while the transcript is being made and ✍ summarizing… while the summary runs. It also covers the moments that used to look like a hang: ⏳ preparing model… if the transcription model has to warm up first, or ⬇ downloading model… if a longer meeting needs a larger summarization model pulled down. The label clears on its own the moment your note lands. See preparing the model for why that first one matters.

Imports get their own state: ⬆ importing… while a transcript or audio file is being brought in.

The pill lives in Obsidian, so you see it when Obsidian is in front of you.

Stopping itself

A recording you forget to stop doesn’t run all afternoon. When both your microphone and the call’s audio have been quiet for five minutes, Oris stops the recording itself and transcription runs as normal. A minute before that happens you get a notification telling you it’s about to, so a long thinking pause is easy to rescue: make any sound and the countdown resets.

Change it, or turn it off, under Settings → Recordings → Auto-stop on silence. There’s a switch, the number of minutes, and a Warn me … seconds before it stops field for the heads-up. Changes apply from your next recording.

How it works underneath

Switching output device in the middle of a recording

Changing where your Mac’s sound comes out in the middle of a meeting used to be the kind of thing that quietly cost you the other side of the conversation. Pair AirPods, plug in a USB audio interface, switch to an external display’s speakers, and the system-audio half of the recording is suddenly bound to a device that isn’t there any more.

Oris notices the switch and reconnects system-audio capture to the new device on its own, without stopping the session. No audio is lost across the change. From your perspective, the recording just keeps going.

Sample rates are re-read, not remembered

Reconnecting mid-recording raises a subtler question: the audio format of the system-audio stream can follow the new device. Switch from 48 kHz speakers to a 44.1 kHz interface and the samples arriving afterwards are 44.1 kHz. If Oris still believed 48 kHz, it would label them wrongly and resample by the wrong ratio. The result is audio that plays back roughly 9% fast, and a transcript made from a pitch-shifted recording.

So the format is read fresh rather than remembered. Oris re-reads it whenever reality can have moved: at the start of a recording, again after every device change, and again if the output device changes its own sample rate without the default device changing at all, which is what happens when you adjust the rate in Audio MIDI Setup, or an app like a DAW drives the device. A format that can’t be read, or that comes back nonsensical, is discarded in favour of the last known-good one rather than adopted.

One consequence is worth knowing about. macOS’s own audio encoder accepts sample rates only up to 48 kHz, so if your output device runs above that (a hi-res DAC at 96 kHz, or the headphone jack configured for 96 kHz in Audio MIDI Setup) the recording is encoded at 48 kHz rather than refusing to start. Nothing is lost that matters here: transcription downsamples to 16 kHz mono regardless.