Declarative OSC bridge for music hardware and software

osc-bridge

面向音乐硬件和软件的声明式 OSC 桥接工具——也是一个可通过大模型驱动的 MCP 服务。

通过 MIDI / SysEx 连接硬件合成器，并通过 OSC 连接 DAW 和现场编程环境（Ableton、Bitwig、Reaper、Sonic Pi、SuperCollider、Pure Data、TouchDesigner、VCV Rack）。每台设备都有一个简洁、命名清晰的 OSC 接口，由一个 JSON 文件（即其驱动）描述；驱动目录位于 SynthHub，服务器一次提供一个驱动。你可以通过现场编程客户端、DAW、脚本、命令行，或通过内置的 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

作为独立桥接工具 / 命令行工具：

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、脚本或大模型来使用它们很不方便：

• 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");

每台合成器都由一个 JSON 文件描述。添加设备无需重新编译 Rust。

驱动来源

驱动目录位于 SynthHub，而非此代码库中：请前往 synthhub.roomi-fields.com 浏览和搜索。osc-bridge 需要时会向 SynthHub 服务请求驱动，每次一个：

• osc-bridge run --device korg/minilogue（驱动 ID）或 --device minilogue （设备的最佳变体对应的 slug）会获取该驱动并将其缓存 （~/.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/）。

特点

• 一个 JSON = 一个驱动。 添加一款合成器只需约 30 行声明式 JSON——CC 编号、SysEx 帧模板、可选参数表。无需 Rust、绑定或构建步骤。提交 PR 后，osc-bridge run 就会加载它。
• 共享目录。 Prophet、Oberheim、Yamaha DX 系列、MatrixBrute、Hydrasynth、Virus TI、Digitone、Matrix-1000……SynthHub 目录涵盖大多数合成器、鼓机和 DAW，并随着用户和 Agent 的贡献不断扩展。可在 synthhub.roomi-fields.com 搜索。
• 硬件和软件兼顾。 同一套具名 OSC 接口既可通过 MIDI/SysEx 驱动硬件合成器，也可通过 OSC 驱动 DAW／现场编码环境——Ableton、Bitwig、Reaper、Sonic Pi、SuperCollider、Pure Data、TouchDesigner、VCV Rack。参见§ 软件目标：DAW 和现场编码环境。
• 内置 MCP 服务。 osc-bridge mcp 会向 Claude（或任何 MCP 客户端）开放 SynthHub 目录——兼具 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 编排。 单个进程可同时驱动多台合成器（osc-bridge orchestrate --config bridge.toml），每台设备都可通过各自的 OSC 前缀访问——例如两台 MatrixBrute 可并列运行，地址分别为 /matrixbrute-1 和 /matrixbrute-2。
• 一流的可重配置控制器支持（Electra One MK2）。 通过一次 OSC 调用即可上传生成的预设；桥接器会解析 JSON，通过 SysEx 重新配置设备，并动态重设自身的 CC↔OSC 路由，让新布局中的每个旋钮都可通过名称访问。通过 OSC 自描述：/bridge/docs 返回集成指南，/electra1/routes/list 返回权威地址表，因此客户端（或由大模型驱动的集成工具）无需将 slug 化规则或协议细节硬编码。参见下文§ 可重配置控制器。
• JSON 不够用时的应急方案。 对于带校验和、缩放方式特殊或有状态的协议设备，可选的每参数 transform／每命令 script 会在 Lua 5.4 沙箱中运行（上限为 1 MiB／10 ms，不允许使用 os／io／加载器）。此功能谨慎使用——osc-bridge lint 会对每次脚本使用发出警告——但它让声明式核心保持精简，同时不必放弃对边缘情况的支持。参见 docs/scripting.md。
• 值得信赖的运行时。 支持按设备限速、感知背压、热路径零分配、无 GC。Windows／Linux／macOS 上均为单个静态二进制文件。

支持的设备

SynthHub 上列出了目录中的合成器、鼓机、控制器、DAW 和现场编码 环境，并注明每个驱动的来源及用户确认情况：

• 🔎 交互式浏览器 → https://synthhub.roomi-fields.com/（可按厂商／型号／作者／来源实时搜索）。
• 🤖 供脚本和 AI Agent 使用 → JSON API：https://synthhub.roomi-fields.com/api/v1/index.json（每个驱动位于 /api/v1/devices/<vendor>/<driver>.json），或托管的 MCP 服务：https://mcp.synthhub.roomi-fields.com/mcp——参见 供 Agent 使用的 API。

每个驱动都会在 _sources[] 中声明来源：✅ hardware-verified、✅ software-verified、📘 vendor-doc、📡 vendor-osc-api / 📡 third-party-osc、🎛️ electra-preset、📦 pencilresearch。

分享你自己的设备

初次接触？30 分钟教程 会带你从头到尾构建一个可用的驱动。否则，以下是三种常见情况，选择适合你的：

列表中没有你的合成器 → 编写它的驱动并提交给 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 工具（驱动会经过检查，然后添加到目录中）；或者在此处提交一个包含该文件的问题。

驱动有误，或你已在硬件上测试过它 → 告知 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 规格无法描述这一点；bridge 将其作为一等场景处理。

这项集成会对整个 Lua 脚本子系统进行严格验证。 MK2 驱动会在真实硬件上（固件 4.1.4，已于 2026-04-14 验证）测试 scripting.rs 层的每项功能：

• 原生 JSON 编解码器（ob.json_decode / ob.json_encode）——在单个 Lua 代码块中解析完整的 Electra 预设（最多 100 KB，包含嵌套页面／设备／组／控制项／叠加层），并符合 500 ms 的 preset_ingest 配置。
• 按设备持久化的状态（ob.state）——驱动会存储当前预设名称，以便 /electra1/preset/current 按需报告该名称。
• 动态 CC↔OSC 路由注册（ob.register_cc_route / ob.clear_routes / ob.set_current_page）——每次上传预设都会从头重建 bridge 的路由表，无需重启。
• 多块 SysEx 发射（ob.emit_sysex）——上传脚本会直接从 Lua 发出封装后的 SysEx 预设数据块。
• 出站 OSC 发射（ob.emit_osc）——为内省端点提供支持：/routes/list、/preset/current、/page/current。
• 带匹配绑定的回复脚本（ctx.bindings）——设备通过 SysEx 报告页面切换时，回复脚本会更新 bridge 的当前页面，使 CC 路由自动跟随硬件 UI。
• 自动加载配套 Markdown——驱动说明（与 JSON 文件放在一起的 electra-one.md）会在启动时加载，并通过 /bridge/docs 提供服务，让由 LLM 驱动的集成工具能够读取设备特有的注意事项（必须使用十六进制颜色、必须提供 inputs[{potId}]、包络段循环手势、MIDI 端口选择等），无需在代码中预先了解这些信息。

上文每项功能都有单元测试、针对真实 .json 驱动的端到端测试，以及经过硬件验证的确认。如果你正在为另一种可重新配置的控制器（Faderfox custom、可编程 MIDI Fighter）构建驱动，Electra 驱动就是模板——复制它的 custom_commands 块，将 JSON→路由解析适配到你的设备预设格式即可。

bridge 的功能

 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 暴露——客户端无需硬编码 slug 转换规则、页面索引或 SysEx 操作码：

发送	接收
/bridge/status	每个已连接设备对应一条 /bridge/status/device <slug> <status>
/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 驱动的集成器只需四步，就能从冷启动开始路由旋钮操作：/bridge/status → /bridge/docs → /electra1/preset/upload → /electra1/routes/list。其他所有内容都在 bridge 内嵌的 Markdown 指南中。

推广到其他可重新配置的控制器

这套机制（DynamicRoutes、ob.register_cc_route、ob.emit_sysex、custom_commands、自动加载配套 .md 文件）与设备无关。添加可重新配置的 Faderfox、自定义 MIDI Fighter Twister 布局或任何可编程控制器，做法都一样：在设备 JSON 中加入一个解析预设的 Lua 代码块，为每个控制项调用 ob.register_cc_route。无需修改核心代码。

安装与快速开始

预编译二进制文件

从 Releases 页面获取最新的 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，即可通过 WebSocket 暴露相同的 OSC 接口：

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

二进制 WS 帧承载原始 OSC 数据包——与 UDP 传输使用的字节完全相同，因此一个无依赖的精简 JS OSC 编码器／解码器就能处理两个方向。每个已连接的 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/ 会列出 bridge 响应的所有 OSC 地址及其类型和值范围，让 OSCQuery 客户端自行构建控件。osc-bridge export --device <driver> --format oscquery|midnam 会导出相同的命名空间，或将驱动程序的 MIDI 名称写入 MIDNAM 文件，供 DAW 使用。参见 docs/EXPORT.md。

设备未显示？（Windows 11 24H2+）

自 2026 年 3 月累积更新（KB5079473）起，Windows 11 搭载了 Microsoft 新推出的 USBMidi2-ACX 驱动，该驱动会执行更严格的 USB 描述符检查。能够通过旧检查、却无法通过新检查的设备，会在设备管理器中显示为 状态：未知，或者绑定到一个只能通过新的 MIDI Services API 访问它们的驱动——midir 无法识别这些设备（因此 osc-bridge 也无法识别），因为 midir 查询的是旧版 MME 接口。

已确认受影响的设备：Polyend Synth / Play / Tracker / Mess / Step （VID 16D0）。可能受影响的设备：描述符不符合新规范的较旧 USB-MIDI 设备。

解决方法——强制使用旧版 usbaudio 驱动：

1. 设备管理器 → 声音、视频和游戏控制器 → 右键单击设备 → 更新驱动程序。
2. 浏览我的电脑以查找驱动程序 → 让我从计算机上的可用驱动程序列表中选取。
3. 选择 USB Audio Device（FR：“Périphérique audio USB”）。如果未显示，请取消勾选“显示兼容硬件”，然后在 Standard USB 部分查找。
4. 安装后，拔下并重新插入 USB 线缆，强制 MME 重新枚举设备。
5. 现在运行 osc-bridge list 应能看到该设备。

如果想了解永久修复的进展，请关注 Microsoft 对 KB5079473 的处理情况——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 会以力度 110 触发 Vermona DRM1 MKIV 的底鼓（音符 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 的工作原理

设备文件声明三项内容：

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"，bridge 会将 OSC 转发到目标的 UDP 端口，而不是通过 MIDI 线缆传输。

两种类型：

声明式驱动——适用于具有固定、文档完善的 OSC 接口的主机软件（通过 AbletonOSC 支持 Ableton，通过 DrivenByMoss 支持 Bitwig，以及 Reaper 原生 OSC）。驱动通过带类型的参数列出 commands[]，并使用 replies[] 接收传入事件。

透传驱动——适用于没有固定 OSC 接口、由用户在项目中自行定义路径的主机软件（Sonic Pi、SuperCollider、Pure Data、TouchDesigner、VCV Rack）。驱动只需声明 transport.passthrough_prefix，bridge 就会原样转发 /<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

每个驱动都附带 SynthHub 上的 .md 说明文档，介绍主机端所需的设置（Remote Script 安装、端口、约定）。

结合 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"]
    }
  }
}

九个本地工具——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 协议系列逐渐明晰后，它发展成了通用声明式 bridge。

许可证

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 架构。