AI - MCP - Refresh Integration

OSC/PAR Bugs and Feature Requests
1

Modified my first OSCPilot sketch with Claude Code today. It copied an existing file, built a new page, inserted the sliders and named them, saved the file. Opened up and worked perfectly. This is a new frontier.

Any thoughts on integration? I would like the ability to refresh a running OSCPilot sketch from modified code, I don’t think the program anticipates that now. Stopping and restarting is a little flow breaking.

I can build a .md description file of all of the JSON workings to educate Claude, if there is an official document that could be published all the better.

I don’t know what is involved in making an MCP (Model Context Protocol) server, but it is really helpful in other programs. Live update, I just asked the steps and get the below information from Claude.

Would be great to get your thoughts. Will probably build a first attempt in the near future.

That narrows it down cleanly — no live OSC needed at all, then. The design is: write a modified .plt JSON, get OSC/PILOT to pick it up. Revised plan:

  1. Nail the JSON schema. The docs give you the conceptual parameter list per widget (Label, Opacity, Background, OSC Address, OSC Socket, MIDI Ch/CC/Note, Circular, OSC Loopback, Read Only, per-widget specifics like Slider’s OSC Low/High or Button’s OSC Off/On, workspace structure, up to 5 OSC sockets A–E, color palette, etc.) but not confirmed JSON key names or nesting. Fastest way to pin this down: save a couple of test projects from the app itself with a few different widget types, tweak one setting at a time, and diff the JSON between saves. A few hours of inspection, not really coding.
  2. Build the MCP server (Python or TS) with tools that construct or patch that JSON structure directly — add/remove/reposition widgets, set OSC address bindings, macros, workspace assignment. Pure file I/O, no network protocol involved.
  3. Write-and-reload tool. Since nothing in the docs describes OSC/PILOT watching an open .plt file for external changes, the reliable path is: write the JSON, then terminate any running instance and relaunch with the documented flags — oscpilot.exe -show C:/Path/To/File.plt -workspace N. Worth a five-minute test on your end first: overwrite the file while the app has it open and see if anything updates without a restart. If it does, you can skip the relaunch step and this gets much smoother; if not, relaunch is the fallback and should be the default design assumption.
  4. Test with the MCP Inspector before wiring to a client.
  5. Register the server locally.

Complexity: lower than the original OSC-peer design — no socket handling, no bidirectional message parsing, just JSON manipulation plus a subprocess relaunch. The real effort is step 1 (schema reverse-engineering), which is inspection work you’re positioned to do quickly since you already have the app and know it’s JSON. Once the schema’s pinned down, the server itself is a small, deterministic project — a few days at most for someone comfortable with Python/JS, likely a couple of evenings.

Local vs. author: still entirely local. You already have what you need — file access and the documented CLI launch flags — no cooperation from the OSC/PILOT developers required.