MPE and external control for the Moog One

Working notes from an interoperability project: getting an MPE controller to play a Moog One with per-note pitch, pressure and timbre, and driving its parameter tree from a computer.

The instrument is internally a small network. An ARM Linux module runs the UI; an XMOS microcontroller (the voice controller) receives MIDI, allocates voices and talks to the analog voice cards. The three speak OSC to each other over UDP and an internal link. Almost everything here follows from mapping that traffic.

Signal flow: how a note gets from a key or a MIDI port to a voice card, where the built-in keyboard and an external controller take different paths, and how per-note MPE fits in.
Protocol: ports, the MIDI-in-OSC encoding, the binary parameter record format, and reply semantics.
Editor: a desktop editor and librarian for the parameter surface, in progress.

Status

Track	What it does	State
Per-note MPE	Voice-controller change so pitch bend, pressure and slide follow each note's origin MIDI channel instead of its timbre, at full polyphony. The voice cards are untouched; they already parse the per-voice messages this relies on.	WORKING all three axes verified on hardware; one unit, one firmware version
Editor / librarian	Desktop editor for the full parameter surface (265 parameters per timbre) over the binary parameter plane, with a small on-device UDP relay and whitelist.	IN PROGRESS software complete against a mock; hardware validation pending
Protocol documentation	Port map, message schemas, parameter id table.	PARTIAL panel plane undecoded

What is published here

Documentation of observed behaviour and interfaces, plus diagrams. Original source code will follow per track as it is cleaned up.

Not published, and not going to be: Moog firmware, in original or modified form, or disassembly and string dumps of it. Anything that eventually ships for the per-note MPE track will be a patch that operates on an image you extract from your own instrument.

Risk. Everything here that sends OSC to the voice controller or modifies it can leave the instrument unresponsive. The controller has no read verb on its parameter port (every argument is a write), and one stray message to a mode address hung it hard enough to need a physical power cycle. Treat the protocol notes as a map, not an invitation.

Tested configuration

One instrument: system firmware 1.5.0, voice controller 2.1.2, voice cards 2.1.0. Nothing here is known to hold on other versions.