First Messages: Wiring MIDI and OSC Between Apps
Learning objectives
- learner can explain what MIDI and OSC each carry (control messages, not audio) and choose between them for a control task
- learner can address an OSC message by IP, port, address pattern and typed arguments so it reaches the right app
- learner can compare MIDI's 7-bit resolution against OSC's 32-bit floats and justify the tradeoff for smooth parameter control
Capstone — one whole task that evidences the objectives
Set up two apps on one machine so app A drives a parameter in app B: route one OSC message (correct IP/port, address pattern, type-tag string, argument) and one MIDI control message end to end, then write a short note explaining which you'd pick for a continuous fader vs a note trigger and why.
Almost every live-coding or hybrid rig eventually needs two programs to talk: a livecoding environment nudging a synth in your DAW, a tablet controller sweeping a visualizer’s hue, a sequencer triggering lighting cues. The whole task here is that first successful wire — one machine, two apps, one OSC message and one MIDI control message each landing where you aimed them. It matters because on stage there is no time to debug plumbing; performers who can wire control paths in minutes get to spend soundcheck making music.
Start supported: with both apps’ docs open, learn what these protocols actually carry — MIDI as a serial control protocol carrying numbered performance messages, never audio, and Open Sound Control as a transport-independent network protocol with typed, address-patterned messages. Then build the OSC leg step by step, leaning on the IP-and-port addressing procedure when the message vanishes into the void (it usually means a port mismatch) and on the type tag string when the receiver gets the message but misparses the value — the classic float-vs-int trap. The MIDI leg reuses the same routing instinct through Channel Voice Messages, picking a CC number to move a parameter. By the capstone you do the whole loop unaided and write the fader-vs-trigger note, which is where the 7-bit versus 32-bit-float resolution comparison earns its keep: zipper-stepped MIDI sweeps versus smooth OSC floats.
Each required atom removes a specific way the capstone fails — wrong mental model, wrong port, wrong type tag, wrong message type, or an unjustified protocol choice. The supporting atom on MIDI Clock sync widens the view to tempo-level coordination between devices: valuable context for multi-app rigs, but not needed to land your first messages. Drill the port wiring and type-tag reading until they are reflexes; they recur in every rig you will ever build.
Atoms in this module
Required — these gate the capstone
Supporting — enrichment, not gating
Part of curricula
- Audio-Visual Performer — integrated, synced live AV — Pair sound and image (unsynced, side by side) required
- Live Visualist — zero to performing live-coded & generative visuals — Reactive & procedural — make it listen, and go to the GPU required
- Shader Artist — real-time GPU craft to a demoscene-grade visual — The demoscene-grade piece: pipeline, reactivity, and release recommended
- VJ — visual performance with projection, light & video — Lock to the music: sync to a DJ or band required
Unlocks — modules that require this one
- Adopting MIDI 2.0, MIDI-CI and Modern Transports
- Building a Portable OSC/MIDI Control Surface for Live Performance
- Controlling Ableton Live Over OSC with AbletonOSC
- Extracting Loudness and Spectrum From Live Audio
- Syncing Tempo and Phase Across Apps with Ableton Link
- Tightening Event Timing in Max and Live