VR Guitar Tuner
Hands-free spatial tuner for Quest 3 passthrough. Tune a real guitar without breaking VR immersion. Rust + DSP, SDK pitch to VR music apps.
TL;DR
- VR-native spatial tuner — anchored to the guitar via passthrough + hand-tracking, head-locked fallback.
- Real-time pitch DSP (autocorrelation + cents), Rust audio path for low-latency analysis.
- Dual model: standalone app + embeddable SDK for third-party VR music apps.
- 10-document strategy stack (BMC, UX, UI, technical, QA, GTM, branding) — planning depth as deliverable.
- Agent-driven dev workflow: scoped skills + hooks in a structured .agents/ directory.
Architecture
Intended architecture (pre-development). Headset mics → Rust DSP pitch detection → spatial UI anchored to the headstock. The same pitch engine is exposed as an SDK for third-party VR music apps.
Problem
VR music apps (Paradiddle, Unplugged, Virtuoso, jam-rooms) are great until a string drifts. Then you pause the experience, lift the headset, find your phone or a clip-on tuner, tune, put the headset back on, re-orient, and lose flow. The whole point of immersion is broken by a 30-second hardware errand. No spatial tuner exists for Quest 3 yet — the gap is obvious once you've tried.
Approach
A standalone Quest 3 / Vision Pro app, plus an SDK third-party VR music apps can embed. The headset's microphones drive a DSP pitch-detection pipeline (autocorrelation + cents-deviation); a 3D spatial tuning interface anchors to the guitar headstock via passthrough hand-tracking, or floats head-locked if the user prefers. Built in Rust for the audio path (latency-sensitive), Wasm for the cross-platform parts, and the Quest SDK on top.
Deep dive
Real-time pitch DSP in Rust
Tuning is a latency problem before it is anything else — the readout has to track the string as it settles, or the player second-guesses it. The intended audio path is native Rust: autocorrelation to lock the fundamental, then cents-deviation for the in-tune/flat/sharp verdict, with the cross-platform pieces compiled to Wasm. Putting the hot loop in Rust rather than a scripting layer is the design choice that keeps analysis responsive enough to trust mid-strum.
Anchoring the UI in passthrough
The whole reason to build this in VR rather than ship another phone app is that the tuner can live on the guitar. Passthrough hand-tracking locates the headstock and pins the tuning readout there, so you glance down at the instrument the way you would with a clip-on tuner — no menu, no context switch. For players who find a world-anchored panel fiddly, a head-locked fallback keeps the readout in view instead. Both modes are specified; neither is built yet.
Standalone app + SDK
There are two deliverables sharing one pitch engine: a standalone Quest 3 / Vision Pro tuner, and an SDK that third-party VR music apps embed so their users never have to leave the experience to tune. The engine is the same code path in both; the surface differs. Right now, though, the honest status is pre-development — the deliverable is a 10-document strategy stack (BMC and financials, project-goal report, UX, UI, technical architecture, QA, GTM, branding, and a master document) plus a scaffolded agent-driven dev workflow. The diagram above is the intended architecture, not a shipped one; the planning depth is the current work product and the binary follows.
Outcome
Pre-development. The deliverable so far is a 10-document strategy stack — BMC + financials, project goal report (W5H, OODA, Pareto), UX (personas, journeys, pre-mortem), UI (mood boards, design system, screen specs), technical architecture, QA strategy, marketing/sales plans, branding, and a master document. The codebase scaffolds an agent-driven dev workflow (Cargo + .agents/ directory of scoped tools per phase). Surfaced here as a strategic R&D case: the planning depth is the work product right now; the binary follows.
Related
