Have something to say?

Tell us how we could make the product more useful to you.

Google Calendar Integration and Automatic Recording

I'd like Vowen to connect to Google Calendar so that when a scheduled meeting starts, Vowen starts recording it. At the moment every recording depends on me remembering to open the app and press start. If I forget, the meeting is gone. There's no going back for it afterwards. This is the main thing I'm missing from Granola. The meeting sits in my calendar, Granola knows it's happening, and the recording starts with the meeting. I don't have to think about it. What I'm asking for: Read-only access to Google Calendar Vowen recognises that a scheduled meeting is starting It begins recording, either automatically or with a one-click prompt if you'd rather not start unattended The note is titled from the calendar event, so I can find it later Most of this already exists. There's meeting detection that triggers when an app starts using the microphone, and it can prompt to take notes. What it can't do is know that a meeting was scheduled, when it was due to start, or what it's called. The calendar connection looks like the missing piece rather than a rebuild. Read-only would be enough. I don't need Vowen writing to my calendar, joining calls or contacting attendees. I'm assessing Granola and Vowen side by side, specifically on meeting note capture and summarisation of transcripts. This is the main gap.

Ian 5 days ago

Export transcript as word-level JSON with per-word timestamps

The transcribe tool already exports as text, subtitles, PDF, plain text, Markdown, SRT, and VTT — that covers most of what I need. The one format I'd love to see added is a word-level JSON export, where every single word has its own start/end timestamp, rather than grouping multiple words or sentences into one timestamp block (like SRT/VTT do). Adobe Premiere Pro already supports this kind of export. Having it in Vowel would help in two main cases: YouTube chapter/timestamp generation. Feeding an AI the current subtitle export gives it far fewer timestamp anchors, since each block often spans multiple sentences. A word-level JSON gives the AI enough granularity to place chapter markers exactly when a topic starts — instead of chapters that start or end mid-sentence because the underlying block was too coarse. Motion graphics / animation timing. When converting a design into a motion graphic to sync with a video, having every word's exact timestamp means I know precisely when to trigger each animation, instead of estimating from a block-level subtitle. This is achievable today by exporting from Premiere Pro instead, but since I'm already using Vowel's transcription for the whole session, having this JSON export available directly from Vowel would save a full extra step.

Dio 14 days ago

Bug: Global hotkey recorder captures the wrong key on non-US keyboard layouts (e.g. French AZERTY)

Environment Vowen version: 0.5.1 OS: Windows 11 Keyboard layout: French (France) AZERTY Description When recording a shortcut in the "Enregistrer le raccourci" (Change Shortcut) dialog and pressing the physical key that produces ² on an AZERTY keyboard (top-left key, next to 1), the dialog does not display or capture ². Instead it shows/records something resembling a quote/accent character. Steps to reproduce Switch Windows keyboard layout to French (France). Open Vowen → Settings → any hotkey (e.g. Hands Free) → "Change Shortcut". Press the physical key that types ² (top-left, next to 1). Expected behavior The recorder captures/displays ², and the resulting shortcut reliably triggers when that physical key is pressed later. Actual behavior The recorder shows a different glyph (looks like an isolated accent/quote mark), not ². Root cause (confirmed at the Windows API level) I traced this down to the OS keyboard layout mapping, not app logic at first, so this reproduces on any layout, not just AZERTY. On the French layout, scan code 0x29 (the physical key that types ²) maps to Virtual Key 0xDE, verified via MapVirtualKeyEx(0x29, MAPVK_VSC_TO_VK_EX, hkl) on the active French HKL. 0xDE is VK_OEM_7, which is hardcoded in most keyboard libraries (including the bundled keyspy dependency — see WinGlobalKeyLookup[0xDE]) with the US-centric generic name "QUOTE", because on a US QWERTY layout VK_OEM_7 is the apostrophe key. So the recorder is displaying the generic US name for the virtual-key slot, not the character actually produced by the physical key on the active layout. GetKeyNameTextW for the same scan code correctly resolves to ², confirming the OS itself knows the right label, it's the app's key-naming table that doesn't. Suspected secondary issue (needs dev confirmation, not fully verified on my end) The app appears to use two different keyboard libraries: keyspy (VK-code based, layout-aware) for the shortcut recorder UI. uiohook-napi (scan-code/physical-position based, layout-independent) for the actual background global-hotkey listener, based on strings like "Backquote" found in its keycode table for this same physical key. If the recorder stores the keyspy-derived name (e.g. "OEM_7") but the runtime listener matches against uiohook-napi-derived names (e.g. "Backquote"), the two would never agree for this class of key on non-US layouts, meaning a shortcut recorded this way might silently never fire even after being "saved" successfully. I wasn't able to fully confirm which naming scheme the live matcher uses at trigger time, but it's worth checking given the mismatch is real between the two bundled libraries' naming tables for OEM/punctuation-row keys. Suggested fix Resolve the key's display name and the stored identifier from the same source used by the background listener, so recorder output always matches what the listener will actually see. When storing an OEM/punctuation-row key, prefer the OS-resolved character (², `, etc., via GetKeyNameText or equivalent) over the hardcoded US-centric VK_OEM_* label, since that label is meaningless to a non-US user. This isn't AZERTY-specific: any layout where OEM-row keys don't match the US layout (German QWERTZ, Spanish, etc.) likely hits the same mismatc

Tqt 18 days ago

Post-Transcription Automations (Auto-Copy & Auto-Export)

As a premium user who transcribes multiple videos daily, my current workflow involves a repetitive, manual loop once a video finishes transcribing: Wait for the "transcription ready" status. Open the completed transcript. Click the three-dots menu. Click Copy. Paste the text into a Large Language Model (LLM) to generate video descriptions and metadata. When processing multiple videos back-to-back, these manual steps add unnecessary friction to an otherwise seamless experience. Proposed Solution Introduce an Automation Toggle or an "On Completion" setting within the manual transcription menu. When a transcription finishes, Vowen would automatically trigger a pre-selected action based on the user's preference: Option A: Auto-Copy to Clipboard (with Smart Restore) — The full transcript text is instantly copied to the user's clipboard the second it's ready, mirroring the smooth workflow of the existing voice transcript feature. To make this even more seamless, it could include a "smart clipboard" behavior: the transcript temporarily occupies the clipboard, but once the user pastes it into their LLM or document, the system automatically restores their previous clipboard data so nothing is permanently lost. Option B: Auto-Trigger Export Window — Automatically opens the export menu immediately upon completion. Option C: Preemptive Default Export — Allows users to set a default format preference (e.g., Markdown, Plain Text, or PDF) so the file is generated and saved automatically without extra clicks. Why This Is Relevant For power users, content creators, and marketers who use Vowen as a baseline reference for AI workflows, transcription is rarely the final step—it is just the catalyst for the next task. Automating the copy/export bridge would eliminate tedious micro-tasks, speed up content distribution workflows, and significantly increase daily productivity.

Dio 2 months ago