FluidVoice on Windows — my parallel Flutter port (status & approach)

[SweetlyTranslateDev]

FluidVoice on Windows — parallel Flutter port (status & approach)

I’ve been working on a parallel Windows port of FluidVoice and wanted to open this up for visibility, feedback, and expectations-setting.

If any of this helps the official Windows version development then hell yeah. I have over a year of very intensive development with STT systems and WASAPI C++ systems while developing my speech to speech translation software. I am more than happy to help with anything or answer any questions anyone may have. I did all of this today so it is not perfect by any means but it works very well since I have been using it today.

Where the work lives

• Fork: SweetlyTranslateDev/FluidVoice_Port_to_Windows
• Branch: windows-port
• Upstream reference: altic-dev/FluidVoice

This is not a rewrite of the macOS Swift app, and it is not full feature parity with macOS FluidVoice. It’s a separate Windows desktop product path that reimplements the core dictation loop with Windows-native tech, while leaving the existing Swift / Xcode tree intact as the reference.

Why this approach

FluidVoice on macOS is deeply tied to Apple platforms (SwiftUI, CoreAudio, Accessibility, CoreML / FluidAudio, notch UI, etc.). A line-by-line Swift→Windows conversion wouldn’t map cleanly.

So the port follows a few rules:

1. Parallel, not destructive — add Windows code alongside the macOS sources; don’t break or relocate the Swift app.
2. WHAT in Dart, HOW in C++ — product logic (PTT state machine, settings, history, AI routing, orchestration) lives in Flutter/Dart. OS/audio/inference glue lives in native plugins.
3. No Electron / Qt — Flutter desktop UI + Win32 / WASAPI / FFI where it matters.
4. Same product loop, Windows technologies — rebuild the behavior with the right Windows APIs rather than forcing macOS patterns onto Windows.

Core loop (what works today)

Hold hotkey (default F8)
  → WASAPI mic capture (16 kHz mono PCM)
  → speech_runtime (Whisper ggml and/or Parakeet ONNX)
  → optional cloud AI output mode
  → inject into focused app
  → overlay / floating HUD + history + tray

How it was built

Architecture

• flutter_app/ — Flutter Windows shell (Home / Models / History / Settings)
• native_plugins/ — C++ plugins for capture, hotkeys, speech, inject, overlay, tray, window chrome, autostart, credentials
• docs/ — port plan, architecture, building, plugin API notes

Dart defines interfaces (AudioCapture, SpeechEngine, TextInjector, hotkey source, etc.). Plugins implement them. The app talks to a unified speech_runtime facade (prepare / transcribe) instead of model-specific plugin APIs.

Native pieces (rough mapping from macOS concepts)

macOS idea	Windows approach
CoreAudio capture	WASAPI plugin → PCM stream into Dart
CGEventTap hotkeys	Win32 low-level keyboard hook → Dart PTT state machine
Whisper / TranscribeCpp	whisper.cpp via speech_runtime (ggml)
FluidAudio / CoreML Parakeet	Parakeet TDT int8 ONNX via sherpa-onnx (batch PTT, not live streaming yet)
Accessibility typing	SendInput → clipboard → UIA fallbacks
Keychain	Windows Credential Manager
Menu bar / notch	System tray + Win32/Flutter overlay / optional floating HUD

Phased delivery

Work landed roughly as:

1. Scaffold + design docs (WINDOWS_PORT_PLAN, architecture)
2. Capture + global hotkeys + Whisper backend
3. Inject, overlay, tray, settings persistence, history
4. Autostart, Credential Manager, AI output modes, local loopback API
5. UI polish (dark shell, acrylic, always-on-top)
6. Parakeet ONNX path + Release packaging (portable zip + Inno Setup installer)
7. Branding, PTT reliability fixes, release notes for “ported vs not yet”
8. Optional floating WaveVisualizer pill + compact always-on-top HUD
9. Multilingual Whisper models (tiny / base) with auto language detect + multilingual font fallbacks

Speech inference runs off the UI thread (worker isolate / native runtime) so ORT / whisper work doesn’t freeze the shell.

What’s included (MVP)

• Global push-to-talk (configurable hotkey)
• Mic device picker + WASAPI capture
• On-device STT:
  • Whisper English: tiny.en, base.en
  • Whisper multilingual: tiny, base (auto-detect)
  • Parakeet TDT 0.6b-v2-int8 (English ONNX)
• Focused-app text injection
• Overlay + optional floating pill / transcript HUD (settings toggle; close can shrink to pill-only)
• Tray (close-to-tray; quit from tray)
• History with retention
• Launch at login
• Always-on-top + acrylic chrome
• Optional OpenAI-compatible enhance / rewrite / write modes
• Optional local HTTP API on loopback
• Portable + installer packaging scripts under scripts/windows/

Models are not bundled; selected models download into AppData on first use. Release builds are strongly preferred for usable STT speed.

What’s intentionally not ported yet

This Windows build does not claim macOS 1.6.x parity. Still missing / out of scope for now:

• Fluid Intelligence / Apple Speech / CoreML stack
• Parakeet Flash / true streaming live STT (Windows path is batch PTT today)
• Broader model catalog parity (Nemotron / Cohere / Parakeet v3 multilingual, etc.)
• Vosk backend (planned later under speech_runtime)
• Command Mode, meeting/file transcription, per-app prompt routing
• Full audio history export, auto-updater, notch UI, etc.

Known soft spots: injection reliability varies by target app; first Parakeet download/load is large; Bluetooth / device-recovery needs more real-world soak.

Docs / build entry points

If you’re exploring the tree:

• WINDOWS.md — quick start
• docs/BUILDING_WINDOWS.md — toolchain & packaging
• docs/WINDOWS_PORT_PLAN.md — original plan / checklist
• docs/ARCHITECTURE.md — layering
• docs/WINDOWS_RELEASE_NOTES.md — ported vs not-yet for release artifacts
• flutter_app/README.md — run / package commands

Why I’m posting this

I want a clear public thread for:

1. Expectations — Windows MVP ≠ macOS FluidVoice feature dump
2. Feedback — especially hotkeys, injection into stubborn apps, STT model choices, and packaging
3. Contributors — if people want to help, the highest-leverage areas are streaming STT, injection edge cases, model catalog expansion, and Windows UX polish

Happy to answer questions about architecture choices (Flutter vs native, whisper.cpp vs sherpa-onnx, why batch PTT first, etc.). If maintainers want this tracked as an issue/project board item instead of (or in addition to) a Discussion, I’m fine with that too.