Declarative OSC bridge for music hardware and software

osc-bridge

音楽ハードウェアとソフトウェア向けの宣言型 OSC ブリッジ。LLM から操作するための MCP サーバーも備えています。

MIDI / SysEx 経由のハードウェアシンセサイザーに加え、OSC 経由の DAW やライブコーディング環境（Ableton、Bitwig、Reaper、Sonic Pi、SuperCollider、Pure Data、TouchDesigner、VCV Rack）にも対応しています。各デバイスには、ドライバーである 1 つの JSON ファイルで定義された、分かりやすい名前付きの OSC インターフェイスが用意されています。ドライバーのカタログは SynthHub にあり、ドライバーを 1 つずつ提供します。ライブコーディングクライアント、DAW、スクリプト、CLI、または組み込みの MCP サーバー（MIDI MCP と OSC MCP）経由で Claude から操作できます。

インストール

ホスト型 MCP サーバー。インストール不要 — osc-bridge のメンテナーが運用する SynthHub サーバーです。カタログ、実際の利用に基づく信頼性、お使いのハードウェアへのリレーを備えています。

• Claude（ウェブ、デスクトップ）：Settings → Connectors → Add custom connector → https://mcp.synthhub.roomi-fields.com/mcp
• Claude Code：claude mcp add --transport http synthhub https://mcp.synthhub.roomi-fields.com/mcp
• Cursor およびその他のクライアント：{"mcpServers": {"synthhub": {"url": "https://mcp.synthhub.roomi-fields.com/mcp"}}}

お使いのマシン上で — stdio 経由の MCP サーバーです。ハードウェア検出と、稼働中のブリッジへの OSC に対応しています（各ドライバーは必要に応じて SynthHub から取得してキャッシュに保存されます。共有する内容は自分で選べます）。

npx -y @roomi-fields/osc-bridge mcp

スタンドアロンのブリッジ／CLIとして：

npm install -g @roomi-fields/osc-bridge      # downloads the prebuilt binary
# or grab a binary directly from the Releases page
osc-bridge run --device arturia/minilab3 --out-port 4   # a driver id, or a JSON file of yours

MCP クライアントの設定とツールについては → docs/MCP.md。MIDI ポートの検出を含むクイックスタート全体については → § インストールとクイックスタート。

ブリッジが必要な理由

最新のシンセサイザーは、ハードウェア、ソフトウェアを問わず、独自仕様で分散したプロトコルを使って MIDI、SysEx、OSC 経由で制御されます。ライブコーディング環境、DAW、スクリプト、LLM から使うのは大変です。

• CC / NRPN のアドレスが分かりにくい
• SysEx のバイト形式はデバイスごとに手作業で作成する必要がある
• 双方向の状態（デバイスが現在把握している状態）を追跡しにくい

osc-bridge は、対応するすべてのシンセサイザーに、分かりやすい名前付きの OSC インターフェイスを提供します。

~mb = NetAddr("127.0.0.1", 7777);
~mb.sendMsg("/minilab3/knob/3/cc_number", 64);     // reconfigure knob 3
~mb.sendMsg("/minilab3/pad/0/color", 127, 0, 0);    // pad 1 red
~mb.sendMsg("/minilab3/display/text", "Hello", "World");

各シンセサイザーは 1 つの JSON ファイルで記述されます。デバイスを追加するために Rust を再コンパイルする必要はありません。

ドライバーの取得元

カタログはこのリポジトリではなく SynthHub にあります。synthhub.roomi-fields.com で閲覧、検索できます。osc-bridge は必要に応じて、SynthHub サーバーにドライバーを 1 つずつリクエストします。

• osc-bridge run --device korg/minilogue（ドライバー ID）または --device minilogue（スラッグ：デバイスの最適なバリアント）を指定すると、ドライバーを取得してキャッシュに保存します（~/.cache/osc-bridge/drivers/、または $XDG_CACHE_HOME、%LOCALAPPDATA%）。
• osc-bridge detect と MCP ツール detect_hardware は、どのメーカーの識別リクエストを送信するかサーバーに問い合わせます。その後、ここで検出された MIDI ポートの名前とデバイスからの応答をサーバーに送信し、一致するドライバーとファームウェアを特定します。list_devices はサーバー上のカタログを検索します。
• オフライン時（osc-bridge privacy --offline on、OSC_BRIDGE_OFFLINE=1）は、キャッシュ済みのドライバーのみを使用し、データは送信されません。

これらのリクエストにアカウント情報は含まれません。お使いのマシン上の JSON ファイルは、そのまま使用されます（--device my-synth.json、osc-bridge mcp --devices-dir my-drivers/）。

他との違い

• 1つの JSON が1つのドライバーになります。 シンセの追加は、CC 番号、SysEx フレームテンプレート、オプションのパラメーターテーブルを宣言的な JSON で記述するだけで、約30行です。Rust もバインディングもビルド手順も不要です。PR を送れば、osc-bridge run が取り込みます。
• 共有カタログです。 Prophet、Oberheim、Yamaha DX ファミリー、MatrixBrute、Hydrasynth、Virus TI、Digitone、Matrix-1000 など、SynthHub のカタログには、ほとんどのシンセ、ドラムマシン、DAW が掲載されており、ユーザーやエージェントからの投稿とともに拡充されます。synthhub.roomi-fields.com で検索できます。
• ハードウェアとソフトウェアの両方に対応します。 同じ名前付き OSC サーフェスを使って、MIDI/SysEx 経由でハードウェアシンセを操作することも、OSC 経由で DAW／ライブコーディング環境を操作することもできます。対応するのは Ableton、Bitwig、Reaper、Sonic Pi、SuperCollider、Pure Data、TouchDesigner、VCV Rack です。§ ソフトウェアターゲットを参照してください。
• MCP サーバーを内蔵しています。 osc-bridge mcp は SynthHub カタログを Claude（または任意の MCP クライアント）に公開します。MIDI MCP と OSC MCP の両方に対応しています。デバイスの検出、デバイスの OSC サーフェスの読み取り、シンセや DAW への OSC 送信が可能です。docs/MCP.mdを参照してください。
• 由来を明確にしています。 各デバイスは _sources[] でソースを宣言します。✅ hardware-verified、✅ software-verified、📘 vendor-doc、📡 vendor-osc-api／📡 third-party-osc、🎛️ electra-preset、📦 pencilresearch です。マッピングがデバイスでテストされたものか、仕様書から採用されたものかを常に確認できます。
• 双方向通信に初期状態から対応します。 受信した MIDI（ノブ操作、SysEx の応答、NRPN）はデコードされ、OSC として再送信されます。複数クライアントへの分配は --osc-client フラグで有効にできます。
• N 対 N のオーケストレーションに対応します。 1つのプロセスで複数のシンセを同時に操作でき（osc-bridge orchestrate --config bridge.toml）、それぞれが独自の OSC プレフィックスでアクセス可能です。そのため、2台の MatrixBrute を /matrixbrute-1 と /matrixbrute-2 として並行して使用できます。
• 再設定可能なコントローラー（Electra One MK2）を第一級でサポートします。 生成したプリセットを OSC 呼び出し1回でアップロードできます。ブリッジは JSON を解析し、SysEx 経由でデバイスを再設定したうえで、CC↔OSC のルーティングを動的に再構成し、新しいレイアウトの各ノブに名前でアクセスできるようにします。OSC 経由の自己記述にも対応しています。/bridge/docs は統合ガイドを返し、/electra1/routes/list は正式なアドレステーブルを返します。そのため、クライアント（または LLM 駆動のインテグレーター）がスラッグ化の方法やプロトコルの詳細をハードコードする必要はありません。以下の§ 再設定可能なコントローラーを参照してください。
• JSON では対応できない場合の拡張手段があります。 チェックサム、特殊なスケーリング、ステートフルなプロトコルを使用するデバイスでは、オプションのパラメーターごとの transform／コマンドごとの script を Lua 5.4 のサンドボックスで実行できます（上限は1 MiB／10 ms、os／io／ローダーは使用不可）。使用は最小限にとどめており、osc-bridge lint はスクリプトの使用をすべて警告しますが、これにより、エッジケースへの対応を諦めることなく、宣言的なコアを小さく保てます。docs/scripting.mdを参照してください。
• 信頼性の高いランタイムです。 デバイスごとのレート制限、バックプレッシャー対応、ホットパスでのメモリー割り当てゼロ、GC なし。Windows／Linux／macOS 向けの単一の静的バイナリです。

対応デバイス

シンセ、ドラムマシン、コントローラー、DAW、ライブコーディング環境のカタログと、各ドライバーのソースおよびユーザーによる確認状況は、SynthHub でご覧いただけます。

• 🔎 インタラクティブなブラウザー → https://synthhub.roomi-fields.com/（ベンダー／モデル／作者／ソースでライブ検索できます）。
• 🤖 スクリプトと AI エージェント向け → https://synthhub.roomi-fields.com/api/v1/index.json の JSON API（各ドライバーは /api/v1/devices/<vendor>/<driver>.json）、または https://mcp.synthhub.roomi-fields.com/mcp のホスト型 MCP サーバー。エージェント向け APIを参照してください。

各ドライバーは _sources[] でソースを宣言します。✅ hardware-verified、✅ software-verified、📘 vendor-doc、📡 vendor-osc-api／📡 third-party-osc、🎛️ electra-preset、📦 pencilresearch です。

独自のデバイスを共有する

初めてですか？ 30分のチュートリアルでは、動作するドライバーを最初から最後まで作成します。それ以外の場合は、よくある3つのケースから選んでください。

お使いのシンセが掲載されていない → ドライバーを作成して SynthHub に送信します。

1. 情報源を探します。メーカーのプログラマー向けリファレンス、MIDI 実装 PDF、または標準的な CSV などです。
2. docs/DEVICE_JSON_SCHEMA.mdに従います。同様のデバイスのドライバー（SynthHub の /api/v1/devices/<id>.json、またはキャッシュ内のコピー）がよいテンプレートになります。
3. 確認します。デバイス上で osc-bridge lint my-synth.json を実行し、続いて osc-bridge run --device my-synth.json を実行します。
4. 提供します。MCP クライアントから submit_driver ツールを使います（内容が検証された後、カタログに追加されます）。または、ファイルを添えてここで issue を作成します。

ドライバーに誤りがある、またはハードウェアでテストした → SynthHub に知らせます。report_result と report_mapping（MCP）で、どのファームウェアで何が動作するかを記録し、submit_fix で学習したマッピングを反映した修正版ドライバーを作成できます。

完全なコントリビューターガイド（スキーマ拡張、バグ報告、Lua による回避策）→ CONTRIBUTING.md。プロトコルを宣言的に表現できないデバイスについては、docs/scripting.mdを参照してください。使用は必要最小限にしてください。使用するたびに osc-bridge lint が警告を出します。

再構成可能なコントローラー（Electra One MK2）— スクリプトによる徹底テスト

ほとんどのシンセはコントロールが固定されており、MiniLab 3 のノブは常に同じ機能を持ちます。Electra One MK2は異なります。216個のコントロールはデバイスにアップロードするプリセットによって定義され、プリセットを変更すると、すべての CC の意味が変わります。静的な JSON 仕様ではこれを記述できないため、ブリッジではこれを主要なユースケースとして扱います。

この統合は、Lua スクリプトサブシステム全体を実環境で徹底検証するものです。 MK2 ドライバーは、実機（ファームウェア 4.1.4、2026-04-14 に検証済み）で scripting.rs レイヤーのすべての機能をテストします。

• ネイティブ JSON コーデック（ob.json_decode / ob.json_encode）— 500 ms の preset_ingest プロファイル内で、単一の Lua ブロックから Electra のプリセット（最大 100 KB のネストされたページ／デバイス／グループ／コントロール／オーバーレイ）を解析します。
• デバイスごとの永続状態（ob.state）— ドライバーはアクティブなプリセット名を保存するため、/electra1/preset/current で必要に応じてその名前を返せます。
• 動的 CC↔OSC ルート登録（ob.register_cc_route / ob.clear_routes / ob.set_current_page）— プリセットをアップロードするたびに、ブリッジのルーティングテーブルを再起動なしで一から再構築します。
• 複数ブロックの SysEx 送信（ob.emit_sysex）— アップロードスクリプトは、ラップされた SysEx プリセットデータブロックを Lua から直接送信します。
• OSC の送信（ob.emit_osc）— イントロスペクション用エンドポイント /routes/list、/preset/current、/page/current を機能させます。
• 対応するバインディングを持つ返信スクリプト（ctx.bindings）— デバイスが SysEx 経由でページ切り替えを報告すると、返信スクリプトがブリッジのアクティブページを更新し、CC ルーティングがハードウェア UI に自動的に追従します。
• 付属 Markdown の自動読み込み— ドライバーのメモ（JSON と同じ場所にある electra-one.md）を起動時に読み込み、/bridge/docs 経由で提供します。そのため、LLM 駆動のインテグレーターは、コード側の知識がなくてもデバイス固有の注意点（16進カラーの要件、inputs[{potId}] が必須であること、エンベロープセグメントの切り替えジェスチャー、MIDI ポートの選択など）を確認できます。

上記の各項目にはユニットテストがあり、実際の .json ドライバーを使ったエンドツーエンドテストも実施済みで、ハードウェアでの検証も完了しています。別の再構成可能なコントローラー（カスタムの Faderfox、プログラム可能な MIDI Fighter など）のドライバーを作成する場合は、Electra ドライバーがテンプレートになります。custom_commands ブロックをコピーし、JSON からルートへの解析をデバイスのプリセット形式に合わせて変更すれば完了です。

ブリッジの機能

 Kanopi / your client                   osc-bridge                     Electra One MK2
─────────────────────                 ────────────────               ────────────────────

 /electra1/preset/upload  ───► parse preset JSON (preset_ingest
   "<preset JSON>"                profile: 500 ms / 4 MiB Lua)
                                ┌─ ob.clear_routes()
                                ├─ ob.register_cc_route × N
                                │    (one per cc7 control,
                                │     per-page, with channel)
                                └─ ob.emit_sysex(…)  ──────────► F0 00 21 45 01 01 <json> F7
                                                                          (reconfigures device)
                                                   ◄────────── F0 00 21 45 7E 01 …  ACK

 (user turns knob on page 2)                     ◄────────── B4 4A 53  (CC#74 ch5 = 83)
                             route lookup: page=2, ch=4, cc=74
                             → /electra1/page2/cutoff 0.65 ───► /electra1/page2/cutoff 0.65

 (user switches page on device)                  ◄────────── F0 00 21 45 7E 06 03 F7
                             reply.script fires:
                             ob.set_current_page(3)
                                                               ───► /electra1/page/switched 3

ゼロからのディスカバリー

デバイス固有の知識はすべて OSC 経由で公開されるため、クライアント側でスラッグ化のルール、ページのインデックス、SysEx オペコードをハードコードする必要はありません。

送信	受信
/bridge/status	接続中のデバイスごとに /bridge/status/device <slug> <status> を1つ受信
/bridge/docs	/bridge/docs/device <slug> <markdown> — 統合ガイド全体（デバイスに付属する .md を自動的に読み込みます）
/electra1/routes/list	N 個の /electra1/routes/entry <addr> <ch> <cc> <page> <min> <max> に続いて /electra1/routes/done を受信
/electra1/preset/current	/electra1/preset/current <name>
/electra1/page/current	/electra1/page/current <n>

LLM 駆動のインテグレーターがコールドスタートからノブ操作のルーティングまでに必要な手順は、わずか4つです。/bridge/status → /bridge/docs → /electra1/preset/upload → /electra1/routes/list。それ以外の情報はすべて、ブリッジ自体に埋め込まれた Markdown ガイドに記載されています。

再構成可能な他のコントローラーへの一般化

仕組み（DynamicRoutes、ob.register_cc_route、ob.emit_sysex、custom_commands、付属 .md の自動読み込み）はデバイスに依存しません。再構成可能な Faderfox、カスタム MIDI Fighter Twister レイアウト、その他のプログラム可能なコントローラーを追加する場合も、デバイス JSON 内にプリセットを解析する Lua ブロックを用意し、各コントロールに対して ob.register_cc_route を呼び出すという同じ手順になります。コアに変更は不要です。

インストールとクイックスタート

ビルド済みバイナリ

リリースページから最新の osc-bridge.exe（Windows）または osc-bridge（Linux/macOS）をダウンロードしてください。

ソースから

git clone https://github.com/roomi-fields/osc-bridge
cd osc-bridge
cargo build --release
./target/release/osc-bridge list

MiniLab 3 の最小ワークフロー

# 1. Find your synth, its driver and its MIDI ports
osc-bridge detect

# 2. Start the bridge
osc-bridge run --device arturia/minilab3 \
  --out-port 4 --in-port 0 \
  --bind 127.0.0.1:7777 --osc-client 127.0.0.1:8888

# 3. From another terminal, send OSC
osc-bridge osc-send /minilab3/display/text "Hello" "World"
osc-bridge osc-send /minilab3/pad/0/color 127 0 0
osc-bridge osc-send /minilab3/knob/3/cc_number 100

受信した MIDI イベント（ノブの操作、パッドの演奏、ピッチベンド、SysEx GET の応答）は、OSC として --osc-client に転送されます。

/minilab3/cc/18 95 0        ← knob moved
/minilab3/note/on 60 127 0
/minilab3/param/value 0 7 0 0 1   ← reply from a /param/get

ブラウザクライアント（WebSocket 経由の OSC）

ブラウザは UDP で通信できません。--ws-bind を指定すると、同じ OSC インターフェースを WebSocket 経由で公開できます。

osc-bridge run --device arturia/minilab3 \
  --out-port 4 --in-port 0 --ws-bind 127.0.0.1:7890

バイナリの WS フレームには生の OSC パケットが格納されます。UDP トランスポートで使われるものと完全に同じバイト列なので、依存関係のない最小限の OSC エンコーダー／デコーダーを JS で用意すれば、双方向に対応できます。接続中の WS クライアントは、それぞれ追加の --osc-client として動作します。すべての送信イベント（デコード済みの MIDI 入力、SysEx 応答、/bridge/status）を受信し、そのフレームは UDP と同じディスパッチ処理を通ります。orchestrate では、bridge.toml の [osc] セクションに ws_bind = "127.0.0.1:7890" を設定します。デフォルトでは無効です。LAN クライアントからの接続が本当に必要な場合を除き、127.0.0.1 で使用してください。

このマシンから配信されたページ（localhost、127.0.0.1）と、ブラウザ以外のクライアントのみ接続できます。ブラウザで開いている他のウェブサイトからの接続は拒否される（HTTP 403）ため、シンセサイザーにアクセスできません。特定のサイトを許可するには、--ws-allow-origin https://example.org を指定します（複数回指定できます。file:// ページには null、すべてのサイトには * を指定します）。または、bridge.toml で ws_allow_origins = [...] を設定します。

OSCQuery と MIDNAM

--oscquery-bind 127.0.0.1:7891（または bridge.toml の [osc] セクションで oscquery_bind）を指定すると、OSCQuery リクエストに応答します。http://127.0.0.1:7891/ には、ブリッジが応答するすべての OSC アドレスとその型および範囲が一覧表示されるため、OSCQuery クライアントは自身でコントロールを構築できます。osc-bridge export --device <driver> --format oscquery|midnam を実行すると、同じ名前空間を出力するか、DAW 用にドライバーの MIDI 名を MIDNAM ファイルとして出力します。docs/EXPORT.mdを参照してください。

デバイスが表示されませんか？（Windows 11 24H2 以降）

2026 年 3 月の累積更新プログラム（KB5079473）以降、Windows 11 には Microsoft の新しい USBMidi2-ACX ドライバーが同梱されており、より厳格な USB ディスクリプター チェックが適用されています。古いチェックには合格しても新しいチェックに失敗するデバイスは、 デバイス マネージャーに 状態：不明 と表示されるか、新しい MIDI Services API 経由でのみ デバイスを公開するドライバーにバインドされます。そのため、レガシー MME インターフェイスを 照会する midir（したがって osc-bridge）からは認識されません。

影響が確認されているデバイス：Polyend Synth / Play / Tracker / Mess / Step （VID 16D0）。影響を受ける可能性が高いデバイス：新しい仕様を満たさないディスクリプターを持つ、古い USB-MIDI デバイス全般。

回避策 — レガシーの usbaudio ドライバーを強制的に使用します。

1. デバイス マネージャー → サウンド、ビデオ、およびゲーム コントローラー → デバイスを右クリック → ドライバーの更新。
2. コンピューターを参照してドライバーを検索 → コンピューター上の利用可能なドライバーの一覧から選択します。
3. USB Audio Device（FR：「Périphérique audio USB」）を選択します。表示されない場合は、 「互換性のあるハードウェアを表示」のチェックを外し、標準 USB セクションを確認します。
4. インストール後、USB ケーブルを抜き差しして MME に再列挙させます。
5. osc-bridge list を実行すると、デバイスが表示されるはずです。

恒久的な修正を望む場合は、KB5079473 に関する Microsoft の対応状況を確認してください。 Pete Brown（Microsoft）はパケットサイズの問題を公に認めましたが、ブロッキングではないと分類しました。 執筆時点では、Polyend によるファームウェア側の修正は発表されていません。

使いやすさ

接続されているシンセはどれで、どのドライバーが適合しますか？

osc-bridge detect

MIDI ポートを一覧表示し、各デバイスに自身の情報を問い合わせます（標準の MIDI Identity Request に続き、ドライバーに記載されたメーカー独自のリクエストを送信します。いずれも無害です）。SynthHub サーバーが オフラインで（ドライバーはここにキャッシュされています）、ドライバー内のファームウェア情報とともに、 返答をドライバーの識別情報ブロックと照合し、すぐに実行できる osc-bridge run の行を出力します。--no-probe は ポート名のみで照合します。

プリセットのバックアップと復元（SysEx ライブラリアン）

osc-bridge backup  --in-port minilab --out backups/minilab3.syx   # then start the dump on the device
osc-bridge restore --out-port minilab backups/minilab3.syx        # overwrites the device's memory

ポートにはインデックスまたは名前の一部を指定できます。backup --request "F0 … F7" --out-port … は最初にダンプ要求を送信します。restore --gap-ms は古いデバイス向けに送信間隔を調整します。

ドラムマシン：名前でサウンドを再生する

ドラムマップを持つドライバーは各ボイスを公開します。/drm1_mkiv/drum/kick 110 は Vermona DRM1 MKIV のキックをベロシティ 110 で鳴らします（ノート 36、チャンネル 10）。デバイスで 複数のトリガーモードが定義されている場合、アドレスにはモードが含まれます。例： /tr_8s/drum/default_note_map/bass_drum。詳しくは DEVICE_JSON_SCHEMA.mdを参照してください。

何も接続せずにデバイス仕様を確認する

osc-bridge inspect arturia/minilab3

OSC トラフィックをリアルタイムでデバッグする

osc-bridge osc-listen --bind 127.0.0.1:8888

SysEx を直接送信する（上級ユーザー向け）

osc-bridge osc-send /minilab3/raw/syx "F0 00 20 6B 7F 42 02 00 16 04 7F 00 00 F7"

デバイス JSON の仕組み

デバイスファイルでは、次の 3 つを定義します。

1. フレーミング — SysEx のヘッダー／フッターのバイト列。
2. コマンド — 高レベルの OSC ルート（パッドの色、ディスプレイのテキスト、プリセットの呼び出しなど）。OSC 引数をプレースホルダーテンプレートに代入してフレームを構築します。
3. パラメーター — 共有オペコードによる一括 GET／SET 用の、パラメーターアドレスのフラットなテーブル。

コード例（arturia/minilab3 ドライバー）：

{
  "commands": [
    {
      "osc": "/pad/{pad}/color",
      "args": [
        {"name":"pad","type":"u7","range":[0,7]},
        {"name":"r","type":"u7"},
        {"name":"g","type":"u7"},
        {"name":"b","type":"u7"},
        {"name":"mode","type":"enum",
         "values":{"user":0,"arturia":1,"daw":2},"default":"user"}
      ],
      "pre": [{"bind":"pad_id","expr":"pad + 4"}],
      "frame": [2, "{mode}", 22, "{pad_id}", "{r}", "{g}", "{b}"]
    }
  ],
  "params": {
    "get_frame": [32, "{pr}", "{p}", "{c}", "{r}"],
    "set_frame": [33, "{pr}", "{p}", "{c}", "{r}", "{val}"],
    "value_type": "u7",
    "entries": [
      {"osc":"/global/backlight", "pr":7, "p":0, "c":0, "r":0, "range":[0,1]}
    ]
  }
}

ソフトウェアの対象 — DAW とライブコーディング環境

osc-bridge はハードウェアシンセサイザー専用ではありません。バージョン 0.10 以降は、DAW とライブコーディング環境も、Prophet や Matriarch と同じ /<env> OSC インターフェースを使う第一級のデバイスとして扱います。ドライバー JSON で device.transport.kind = "osc" を宣言すると、ブリッジは MIDI ケーブルを介さず、OSC を対象の UDP ポートに転送します。

2 つの方式があります。

宣言型ドライバー — AbletonOSC を介した Ableton（AbletonOSC）、DrivenByMoss を介した Bitwig（DrivenByMoss）、Reaper のネイティブ OSC など、ホストソフトウェアに固定されたドキュメント化済みの OSC インターフェースがある場合に使います。ドライバーでは型付き引数を持つ commands[] と、受信イベント用の replies[] を列挙します。

パススルードライバー — ホストソフトウェアに固定の OSC インターフェースがなく、各ユーザーがプロジェクト内でパスを独自に定義する場合に使います（Sonic Pi、SuperCollider、Pure Data、TouchDesigner、VCV Rack）。ドライバーでは transport.passthrough_prefix を宣言するだけで、ブリッジは /<env>/... 以下のすべてをそのまま転送します。返信は、プレフィックスを付けて反対方向に送られます。

現在、以下をサポートしています。

対象	モード	ステータス
Ableton Live 12.2.7 + AbletonOSC	宣言型	✅ ソフトウェアで検証済み
Bitwig Studio + DrivenByMoss	宣言型	📡 サードパーティー OSC
Reaper 7（Default.ReaperOSC）	宣言型	📡 ベンダー OSC API
Sonic Pi 4.5	パススルー	📡 ベンダー OSC API
SuperCollider sclang 3.13	パススルー	📡 ベンダー OSC API
Pure Data 0.55-x	パススルー	📡 ベンダー OSC API
TouchDesigner 2023	パススルー	📡 ベンダー OSC API
VCV Rack 2 + vcv-osc プラグイン	パススルー	📡 サードパーティー OSC

各ドライバーには、ホスト側で必要な設定（Remote Script のインストール、ポート、規約）を説明する .md の注記が SynthHub に付属しています。

osc-bridge orchestrate と組み合わせれば、ハードウェアの MiniLab 3、Ableton Live、Sonic Pi のループを単一のプロセスから操作できます。bridge.toml の新しい [[routes]] セクションを使うと、クライアントコードを書かずに、MiniLab のノブを回して Ableton のトラック音量や Sonic Pi のキューを操作できます。

[osc]
bind = "127.0.0.1:7777"
clients = ["127.0.0.1:8888"]
# ws_bind = "127.0.0.1:7890"   # optional — browser clients over WebSocket

[[devices]]
spec = "arturia/minilab3"      # a driver id or slug, or a JSON file
midi_out_port = 4
midi_in_port = 0

[[devices]]
spec = "ableton/live.third-party-osc.fw-12.2"   # AbletonOSC: no MIDI port needed

[[routes]]
from = "/minilab3/cc/74"
to = "/ableton/track/0/volume"
map.from = [0, 127]
map.to = [0, 1]

MCP 経由で Claude から使用する

osc-bridge にはModel Context Protocolサーバーが付属しています。MIDI MCPとOSC MCPの両方に対応しています。任意の MCP クライアントを接続すると、モデルは SynthHub カタログを参照し、デバイスの OSC インターフェースを読み取り、シンセや DAW に OSC を送信できます。

ホステッド — https://mcp.synthhub.roomi-fields.com/mcp をリモート MCP サーバーとして追加します（インストールを参照）。インストールは不要です。シンセはリレーページ synthhub.roomi-fields.com/connect から接続します。

お使いのマシン上での実行：

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

ローカルツールは 9 つあります — list_devices、get_device_docs、list_routes、export_device、send、get_status、detect_hardware、backup_presets、restore_presets — さらにサーバー側の機能として、レポート、信頼、コントリビューション、共有プリセット（検索、読み込み、シンセから取得、共有）があります。その後、会話の中で次のように依頼できます。 「MatrixBrute では何ができますか？ フィルターのカットオフをスイープしてください。」 — モデルが list_routes("matrixbrute") を呼び出し、続いて send を実行します。接着コードは不要です。

設定手順全般 — Claude Desktop / Cursor の設定、ワークフロー、ソフトウェア対象の操作については、docs/MCP.md を参照してください。

プロジェクトの始まり

MatrixBrute 用 OSC ドライバーとして始まりました（パッチ形式は、GPL-3 の sysex-controls とコミュニティ製の MBPV ツールを基にリバースエンジニアリングしました）。Arturia のプロトコルファミリーの全体像が明らかになるにつれ、汎用の宣言型ブリッジへと発展しました。

ライセンス

AGPL-3.0-or-later。改変版をネットワークサービスとして実行する場合、そのサービスのユーザーにソースコードを提供する義務があります。MiniLab 3 のパラメーターテーブルの基礎となった sysex-controls のリバースエンジニアリング成果物は GPL-3.0 であり、GPL-3.0 の第 13 条により AGPL-3.0 コードとの組み合わせが認められています。

サードパーティ製デバイスデータ

ドライバーカタログはSynthHubのもので、各ドライバーの出典のクレジットとライセンスは_sources[]に記載されています。テスト用にここに残されている一部のドライバー（tests/fixtures/devices/）についても同様です。pencilresearch型のものは、Pencil ResearchとコントリビューターによるMIDI Guideを基に改変したもので、ライセンスはCC BY-SA 4.0です（出典：pencilresearch/midi）。それぞれにライセンス、クレジット表記、正確な上流CSVとコミットが記録されています。加えた変更は、CSVの行をosc-bridgeのJSONスキーマに変換したことです。