op-bridge

op-bridge connects any MCP client (Claude Desktop, Claude Code, Codex, or claude.ai and ChatGPT through a tunnel) to an OP-1 field plugged into a Mac. The model picks and designs sounds, plays scores with velocity, automation and pitch bend, runs the tape and mixer, writes presets, and programs drums and sequencers. The Field is the instrument and the studio; the computer only sends MIDI and listens.

The listening is the point. Every take is recorded from the Field's USB audio and measured, so the model works from what came out of the device, not from what it meant to send.

What happens when you ask it to play something

1. It orients itself. The server's instructions send the model to get_guide("quickstart") and get_status: is the Field connected, which mode the human has set, what the bridge last set on the device (the Field cannot be queried), and whether a job is already running.

2. It chooses a sound from what is known. Palette notes, slot_profile (engine, playable range), find_sounds over an index of audited slots, then audition_slots to hear the candidates in one call.

3. It writes a score and checks it. validate_score checks the notes against the Field's voices and range and, in guided mode, the session's key, tempo and parameter limits, before anything plays.

4. It plays and records. play(score, record=true) sets the Field's tempo to the score's, sends notes, CC automation, pitch bend and MIDI clock, and records the USB audio at the same time. Anything longer than about 25 seconds returns a job_id at once; the model polls job_status for the same result a direct call would give.

5. It reads what was heard. A real rehearsal take from 2026-09-30, trimmed (values from the take's JSON sidecar):

   {
     "take_id": "reh-voices-37-40-20260930-201215",
     "analysis": {
       "live_usb_channels": [3, 4],                       // the selected tape track's pair
       "main_mix": {"peak_db": -9.1, "rms_db": -26.4, "clipping_fraction": 0.0},
       "peak_db": -14.2, "rms_db": -31.0, "clipping_fraction": 0.0,
       "spectral_centroid_hz": {"median": 3996, "min": 1686, "max": 5192},
       "notes_checked": 16, "notes_heard": 16,
       "notes": [
         {"beat": 0.0, "pitch": "F#4", "heard": true, "prominence_db": 43.9, "onset_offset_ms": -4.5}
         // ... 15 more
       ]
     },
     "spectrogram": "view_spectrogram(\"reh-voices-37-40-20260930-201215\")"
   }

   Then it looks: view_spectrogram returns the image below, and measure_take adds band levels, a pitch track, harmonics and periodic movement when a question needs them.

6. It asks for hands when it needs them. Arming a tape track is something MIDI cannot do, so the model calls human_steps("arm_recording") and relays the exact key presses, then record_to_tape commits the part. backup_tape keeps the stems on the Mac.

Both images are exactly what the model receives from view_spectrogram, rendered by op-bridge from takes recorded off the Field's USB audio on 2026-09-30. Time runs left to right, 0 to 8 kHz bottom to top; the red mark is the score start.

Related MCP server: synthlab-mcp

How it works

flowchart LR
    model["AI model<br/>in any MCP client"]
    bridge["op-bridge<br/>MCP server"]
    field["OP-1 field"]
    take["take on disk<br/>WAV + JSON + spectrogram"]
    human(["human at the device"])

    model -->|"tool call, e.g. play(score)"| bridge
    bridge -->|"USB MIDI: notes, CC, clock"| field
    field -->|"USB audio: 8 or 10 channels"| bridge
    bridge -->|"record and analyse"| take
    take -->|"notes heard, levels, timing, image"| model
    bridge -.->|"human_steps: exact key presses"| human
    human -.->|"arm record, disk mode"| field

The server is one Python process (src/op_bridge/server.py) speaking MCP over stdio, or Streamable HTTP for remote connectors. One lock guards the device, so two tool calls never drive it at once.

What it can do

The full surface, 72 tools in ten groups, is in docs/tools.md.

Making a finicky device reliable and honest

The OP-1 field was not built to be driven by software. It cannot report its state, ignores notes on the wrong channel, silently turns a malformed preset into a sample, and needs a human for several steps. These are the decisions that make the integration dependable, with the file that shows each.

Quick start

You need an OP-1 field on USB-C in normal mode, a Mac, Python 3.11+ and uv.

git clone https://github.com/CrabbTech/op-bridge.git && cd op-bridge
uv sync
uv run op-bridge status        # shows whether the Field's MIDI port and audio device are visible

On the Field (hold shift + COM, then T1): set midi to channel 1 with clock, notes and other enabled, and usb audio to 10 channel so the main mix is captured. Grant microphone permission the first time macOS asks. Then add the server to your client, for example Claude Code:

claude mcp add op-bridge -- uv --directory /ABSOLUTE/PATH/op-bridge run op-bridge serve

Claude Desktop, Codex CLI, and claude.ai or ChatGPT over a tunnel are in docs/setup.md. Ask for something ("play a slow four-bar progression on synth 3 and tell me what you heard"); the model takes it from there.

Files

Everything the bridge records is stored under ~/Music/op-bridge (or OP_BRIDGE_HOME): sessions of takes, seeds, samples and backups, presets staged for the next disk-mode round, and field-backup/ copies of every slot file it replaces. The full layout is in docs/setup.md.

Tests

uv run pytest -q

All tests are functional. Without a Field attached the device-dependent ones skip themselves (currently 140 passed, 12 skipped), and OP_BRIDGE_HOME points at a temporary directory.

Documentation

• docs/setup.md: install, Field settings, every client, modes, CLI, secrets, files.

• docs/tools.md: capabilities and all 72 tools, grouped.

• docs/listening.md: measurements, spectrograms, the optional local and Google listeners.

• docs/device.md: the device brief and what was measured on a real Field (served to the model as get_guide("device")).

• docs/reference/: how to add your own copy of Teenage Engineering's user guide and MIDI tables; they are not distributed here.

About

Built by Tyler Crabb, working with AI coding agents (Claude Code and Codex), and exercised against a real OP-1 field; docs/device.md records what was verified on the device.

op-bridge is an independent project, not affiliated with or endorsed by Teenage Engineering. OP-1 is a trademark of Teenage Engineering.

Released under the MIT licence.