lognote is now Oris — same local-first meeting notes, new name.

Skip to content
Releases 0.7

The editor is optional

The most common piece of feedback from early users: “I had to open Obsidian just to start a recording.” You’re about to jump on a call, the editor isn’t running, and there’s a context switch before you’ve even joined the meeting. Small friction, but it adds up.

0.7 removes that dependency. Obsidian is still the richest way to use Oris (cursor-anchored notes, rename-following, the full plugin command set), but it’s no longer a prerequisite for recording.

A record strip in the app

The Oris app now has a record strip, a persistent bar that sits above the tabs, visible everywhere in the app. It starts and stops a meeting recording, shows which destination the note will land in, warns you before you hit record if something’s wrong with that destination, and opens the finished note once transcription and summarization are done.

The full workflow without opening anything else: press record in Oris, take the call, press stop, wait a few minutes, read the note. System audio and your microphone are captured the same way regardless of which surface you use.

If Obsidian is open and your cursor is parked in a note, recording from there still works exactly as before. The plugin’s start/stop command, cursor-anchored insertion, and rename-following are all unchanged. The strip and the plugin both control the same underlying recording, so you can stop from either one. There’s no mode to select; whichever surface you use, the result is the same note in the same place.

App stripObsidian pluginRecordingFinished note start / stop start / stop transcribe, summarize

If your configured destination has a problem, you see it before you’re on the call. The strip shows a warning for a vault that’s moved, a folder that no longer exists, or a path that needs permissions.

Where the note goes

Before this release, “where does Oris write?” had one answer — your Obsidian vault. That ruled out a folder of plain Markdown files, a machine without Obsidian installed, and anyone who wants notes as durable files they can grep, sync, or open in any editor.

Onboarding now asks directly. The choices are an Obsidian vault (same behavior as before) or a Markdown folder — any writable directory on your Mac.

With a folder destination, each recording lands as a new file named by date, time, and meeting title. The filename follows {date} {time} {title}.md. Awkward characters in the title are cleaned before they hit the filename; if a file with that name already exists, Oris appends a suffix rather than overwriting it. The content is plain Markdown in the same format as vault output, with a TL;DR, decisions, action items, and a speaker-labeled transcript. You can open these files in any editor, put the folder in iCloud Drive or Dropbox, and treat them like any other plain-text notes.

Apple Notes and Notion are on the roadmap for destinations. Today it’s vault or folder.

DestinationObsidian vaultMarkdown folderInline at cursordate-time-title.md cursor-anchored new file

Existing setups carry over

If you’re already set up with a vault, nothing changes on your end. First launch after the update migrates the implicit vault configuration to an explicit destination profile automatically. Output is byte-identical, with the same files, Markdown format, and note structure. The pipeline tests verify this end-to-end.

The guided walkthrough doesn’t re-run. Your configured transcription language, summarization provider, API keys, and recordings history are all preserved.

When a delivery doesn’t land

Before 0.7, a failed note delivery could disappear without a trace. A write to a locked note, a crash mid-write, or an edge case in the delivery path, and the meeting’s transcript was just gone.

The Recordings tab now has an “Awaiting delivery” section that appears whenever something is waiting. Each item shows what’s waiting, where it was going, and why it stopped. What you can do depends on the situation.

  • A clean failure offers Retry.
  • An outcome Oris couldn’t determine (the write may or may not have reached the destination) offers Mark delivered, with a prompt to check the destination yourself rather than risk a duplicate.
  • A quick note that stalled offers Mark delivered too, since its text is already safe in the in-app inbox. The real recovery path is the Quick Notes viewer’s Send to vault; the item clears once you’ve handled it.

When nothing is waiting, the section doesn’t appear. The tab doesn’t accumulate clutter.

Finished recordingSave locallyWrite noteReceiptOutboxAwaiting delivery on success on failure

One delivery core

Every finished recording in 0.7 flows through a single delivery path with receipts. Before attempting to write a note, Oris saves the transcript and summary to local state. If the write fails, the saved copy goes to an outbox rather than being discarded. If the app crashes mid-write, the copy survives the restart and the outbox item appears on next launch. A receipt records a successful delivery, so a retry or recovery that finds the note already in the destination skips rather than writing a duplicate.

Under normal conditions, none of this is visible. The “Awaiting delivery” surface exists for the cases where things don’t go normally.

The contract for this path froze with this release. Any future change to output format, destination types, or note structure has to account for the delivery layer explicitly, which closes the quiet class of bugs where a plumbing change accidentally broke note delivery.


← all posts