The idea
Provide a physical meeting control and unmistakable recording status beside the computer. V1 is a USB status/control accessory paired with a host application. It does not independently capture every application's audio or bypass operating-system permissions. The host performs capture, transcription, storage and deletion.
The connection
A small object makes an invisible software state tangible. The important interaction is knowing what the computer is doing and being able to stop or mark it deliberately.
How it could work
Use a simple documented USB protocol rather than pretending to be storage or silently injecting keystrokes. A serial or HID interface can carry button events and status, while the host owns session state. The ESP32-S3 supports TinyUSB-based device development; select the board and current framework revision after checking USB wiring and supported classes.
The device must display confirmed host state, not simply light up when its button is pressed. Give each command an ID and require an acknowledgement. If the host heartbeat disappears, display UNKNOWN or DISCONNECTED instead of falsely showing recording stopped. A local stop request should remain visibly pending until the host confirms it.
What would prove it
Run 20 mock sessions with spoken reference phrases and bookmark events. Unplug USB mid-session, suspend the host, restart the companion app and revoke capture permission. Compare device display, host state and actual saved audio across every transition.
Proposed gate: no display claims recording is active before host confirmation; loss of heartbeat becomes visible within two seconds; repeated start/stop commands do not create duplicate sessions; bookmarks land within one second of their intended position; deletion removes the selected local session and reports any external copies separately. Transcription accuracy is assessed against the reference script rather than described as perfect.
The path to a complete build
- Implement the host capture app and permission/error states with a simulated accessory.
- Connect the device and implement acknowledged commands plus heartbeat expiry.
- Add bookmark, export and local deletion; test interrupted writes.
- Make a readable enclosure that does not block adjacent USB ports; a short cable may be preferable.
- Package a protocol document, installation instructions, supported-host matrix and recorded fault tests.
Open the engineering notebook
Components, interfaces and calculations
BOM: USB-capable development board, small OLED/TFT, physical start/stop or bookmark button, status LED, cable and enclosure. Start with one operating system and one explicitly selected audio input. Use existing audio hardware instead of adding a microphone to the stick in V1.
Define messages such as START_REQUEST, STOP_REQUEST, BOOKMARK and STATE with session ID, command ID and timestamp. The host validates and acknowledges transitions. Keep session folders separated and save transcripts incrementally. Meeting participants need a clear recording indication; retention and deletion should be explicit features, not hidden settings.
Scope and development questions
Allow 5–8 sessions for one supported host platform. Hardware is only part of the cost: estimate transcription minutes, storage, support and any hosted processing separately. Resolve whether the user needs their microphone alone or meeting-system audio, whether offline transcription is mandatory and the target operating system. Cross-platform audio capture should be a later milestone.