A high-performance, low-latency bridge between Synesthesia VJ software and the wider lighting ecosystem — Hue, Nanoleaf, WLED, DMX, lasers, and beyond.
Status: Planning complete · M1 ready to start Author: Aaron Cupp (@iammrcupp) Organization: @audiophore Website: audiophore.dev · alias audiophore.com License (planned): MIT OR Apache-2.0 Language: Rust (with Lua scripting for user-facing show logic) Deployment target: Native desktop app — macOS Apple Silicon (primary), macOS Intel + Linux x86_64/ARM64 (tested). Docker / OCI container kept as a deferred future option.
Audiophore — from audio + the Greek suffix -phore (φόρος, "bearer" or "carrier"), as in semaphore (sign-bearer) or phosphor (light-bearer). An audiophore carries audio. Audiophore the project carries audio analysis into the lighting domain — turning what a kick drum, a bass swell, or a scene change in Synesthesia means into what every light, panel, fixture, and laser in the room does.
Audiophore takes the rich audio analysis data that Synesthesia Pro emits over OSC — FFT bands, beat detection, BPM tracking, scene palettes — and translates it into native protocols for every kind of lighting hardware a performing VJ or DJ might want to drive: Philips Hue Entertainment, WLED via E1.31/sACN/DDP, Art-Net DMX rigs, Nanoleaf panels, ILDA lasers via Ether Dream, and OSC passthrough to other software (Liberation, Resolume, etc.).
The goal is a single piece of software that lets a performer write one show file describing what they want lighting to do, and have it adapt to whatever hardware is actually present at a given venue.
Synesthesia is exceptionally good at audio analysis and shader-driven visuals, but its lighting integrations end at "screen output." Resolume's DMX is clunky. TouchDesigner can do anything, but only if you are a TouchDesigner programmer. Hue/Nanoleaf/WLED users have no good path to real-time, beat-locked, scene-aware control from VJ software. Laser people live in their own walled garden. There is no universal bridge.
Audiophore is that bridge.
Three reasons, in order of importance:
- Latency. Kick-drum-to-light needs to be under 30ms total to feel locked-in on stage. Rust's predictable performance and lack of GC pauses matter here.
- Reliability. This software runs live, in front of audiences, on sketchy venue networks. Memory safety eliminates a whole class of failure.
- Distribution. Single static binary, trivially cross-compiled to a Raspberry Pi for the eventual hardware-appliance product.
This directory contains the planning artifacts for the project. Read in this order if you are new:
| Document | Purpose |
|---|---|
README.md (this file) |
Project overview |
SESSION_HANDOFF.md |
Start here when bootstrapping an implementation session. Locked decisions, M1 deliverables, first-commit checklist. |
PLAN_OF_ACTION.md |
High-level roadmap, milestones, success criteria |
IMPLEMENTATION_PLAN.md |
Concrete technical plan — crates, types, code structure |
HARDWARE.md |
What to buy and where, for development |
DEPLOYMENT.md |
Native desktop app packaging across macOS + Linux; CI build matrix; archived Docker/K8s appendix for reference |
SYNESTHESIA_OSC.md |
Synesthesia Pro OSC schema and audio uniform reference |
PROTOCOLS.md |
Notes on every output protocol (Hue, E1.31, Art-Net, DDP, Ether Dream, etc.) |
RUST_ECOSYSTEM.md |
Crates evaluated, dependency choices, gaps to fill |
┌──────────────────────────────────────────────────────────────┐
│ INPUTS │
│ Synesthesia OSC │ Audio loopback FFT │ MIDI clock │
│ Ableton Link │ Manual / web UI │
└────────────────┬─────────────────────────────────────────────┘
│ normalized event stream
▼
┌──────────────────────────────────────────────────────────────┐
│ EVENT BUS (in-process) │
│ arc-swap snapshots, 60–120 Hz tick │
└────────────────┬─────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ MAPPING / PROGRAMMING LAYER │
│ Show files: TOML config + Lua scripted modes │
│ Cues, scenes, palettes, zone definitions │
└────────────────┬─────────────────────────────────────────────┘
│ resolved frame: {device_id: [pixel/dmx data]}
▼
┌──────────────────────────────────────────────────────────────┐
│ OUTPUTS │
│ Hue Entertainment │ WLED / E1.31 / sACN │ Art-Net / DMX │
│ Nanoleaf Streaming │ DDP │ Ether Dream │
│ OSC out (→ Liberation, Resolume, anything) │
└──────────────────────────────────────────────────────────────┘
| Metric | Target |
|---|---|
| Audio-event-to-light latency (our code only) | < 10ms |
| End-to-end latency (kick → light) | < 30ms |
| Concurrent pixels at 60Hz | 1000+ |
| Memory footprint (idle, single output) | < 50MB |
| Binary size (stripped, release) | < 15MB |
- M1 — Proof of life (~2 weekends): Synesthesia OSC → WLED via E1.31, hardcoded.
- M2 — Real engine (~4–6 weekends): TOML+Lua show files, Hue + Art-Net adapters, web UI.
- M3 — Lasers + polish (~3–4 weekends): Ether Dream, Liberation passthrough, portable shows, public release.
- M4+ — Appliance, marketplace, growth.
See PLAN_OF_ACTION.md for detail.
- Synesthesia Pro license owned
- Project named: Audiophore
- GitHub organization created: @audiophore
- Org profile README published
- Domains registered: audiophore.dev (primary) + audiophore.com (redirect)
- Dev hardware ordered (see
HARDWARE.md) - Domain DNS pointed at cluster ingress
- Placeholder landing page deployed at audiophore.dev
-
audiophore/audiophoreworkspace skeleton committed - M1 milestone reached (Synesthesia OSC → WLED proof-of-life)
Licensed under either of MIT or Apache 2.0 at your option.