MCP.so
登录

Declarative OSC bridge for music hardware and software MCP Serve…

@roomi-fields

基本信息

分类

开发工具

许可证

NOASSERTION

传输方式

stdio

作者

roomi-fields

提交者

roomi-fields

关于 Declarative OSC bridge for music hardware and software MCP Server

OSC ↔ MIDI/SysEx bridge for 849 hardware synths and music software (Ableton, Bitwig, Reaper, Sonic Pi). A MIDI MCP and OSC MCP for Claude.

#music#rust#osc#midi#mcp#daw#synthesizer#live-coding#supercollider#reaper#moog#ableton#bitwig#sysex#claude#arturia#model-context-protocol#mcp-server#hardware-synth#osc-bridge

Declarative OSC bridge for music hardware and software MCP Server 配置

使用下面的配置,将此服务器添加到你的 MCP 客户端。

{
  "mcpServers": {
    "osc-bridge": {
      "command": "npx",
      "args": [
        "-y",
        "@roomi-fields/osc-bridge",
        "mcp"
      ]
    }
  }
}

Declarative OSC bridge for music hardware and software MCP Server 工具

工具列表暂未提供

当前收录暂时没有可展示的工具列表,不代表服务没有工具。请查阅项目文档了解支持的能力。

点击上方按钮,在临时沙箱中运行此服务器并实时获取工具列表。

概览

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

常见问题

1

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/>.

2

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.

3

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.

4

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.

5

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.

评论

开发工具 分类下的更多 MCP 服务器