概要
What is Declarative OSC bridge for music hardware and software?
It is an MCP server that provides a declarative bridge between music hardware (synthesizers over MIDI/SysEx) and software (DAWs and live-coding environments over OSC). It supports 849 devices across 187 vendors and includes a built-in MIDI MCP and OSC MCP to drive everything from an LLM like Claude.
How to use Declarative OSC bridge for music hardware and software?
Run it as an MCP server with npx -y @roomi-fields/osc-bridge mcp, then configure your MCP client (e.g., Claude Desktop) to point to that command. Each supported device is described by one JSON file, so you can control synths and DAWs via named OSC addresses after startup.
Key features of Declarative OSC bridge for music hardware and software
- One JSON file per device driver; no Rust recompilation needed
- 849 hardware/software devices supported out of the box
- Bridges MIDI/SysEx hardware and OSC software (Ableton, Bitwig, etc.)
- Built-in MCP server exposes the whole catalogue to LLMs
- Bidirectional: incoming MIDI decoded and re‑emitted as OSC
- Rate‑limited, backpressure‑aware, zero‑alloc hot path runtime
- Reconfigurable controllers with Lua scripting escape hatch
Use cases of Declarative OSC bridge for music hardware and software
- Control hardware synthesizers from live‑coding environments (SuperCollider, Sonic Pi) or DAWs
- Drive Ableton Live, Bitwig Studio, or Reaper from scripts or an LLM via OSC
- Orchestrate multiple synths simultaneously with N‑to‑N fan‑out
- Let an LLM (Claude) discover and control music gear using the MCP tools
FAQ from Declarative OSC bridge for music hardware and software
What devices are supported?
The bridge supports 849 devices across 187 vendors, including Moog, Arturia, Roland, Yamaha, Ableton, Bitwig, and many more. Devices are categorised by verification status (hardware‑verified, software‑verified, vendor‑doc derived, etc.). A full searchable catalogue is at https://roomi-fields.github.io/osc-bridge/.
How do I add a new device?
Open a pull request adding a JSON file under devices/<vendor>/<slug>.json. The 30‑minute tutorial in docs/TUTORIAL_FIRST_DEVICE.md walks you through building a driver. Devices must cite a source (vendor documentation, third‑party CSV, etc.); contributions that promote a device from “doc‑derived” to “hardware‑verified” are especially welcome.
How is this different from other MIDI/OSC bridges?
Each device gets a single declarative JSON file as its driver — no Rust code, no build step. The bridge handles both hardware (MIDI/SysEx) and software (OSC) with the same named OSC surface, supports bidirectional feedback, and includes a built‑in MCP server for LLM control. It also provides honest provenance markers so you know whether a mapping was tested on real hardware.
What runtime dependencies does it require?
It is distributed as a single static binary for Windows, Linux, and macOS. No runtime dependencies, no garbage collector, no separate bridge process needed. For MCP usage, only Node.js is needed to run the npx command that launches the pre‑built binary.
How does authentication or transport work?
The MCP server uses standard stdio transport (the command runs as a subprocess of the MCP client). For OSC, it listens on the ports defined in device JSON files (defaults shown in the documentation). No authentication layer is described — the bridge is intended for local or trusted network use.
