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.

コメント

「開発者ツール」の他のコンテンツ