home/ modules/ wiring-osc-and-midi-first-messages

First Messages: Wiring MIDI and OSC Between Apps

  • 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

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

MIDI is a serial control protocol carrying numbered performance messages, never audio waveforms
Concept L1 Foundations JB
Open Sound Control is a transport-independent network protocol carrying typed, address-patterned messages between devices
Concept L1 Foundations JEN
An OSC message has two parts: an address pattern (the parameter name) and one or more typed arguments (the values)
Concept L1 Foundations JN
OSC connections require both a destination IP address and a port number to route messages to the correct application
Procedure L1 Foundations JN
Every OSC message carries a type tag string that encodes the data type of each argument
Concept L1 Foundations J
OSC's 32-bit float arguments provide far higher control resolution than MIDI's 7-bit (0–127) integer range
Concept L1 Foundations JN
MIDI Channel Voice Messages carry per-note performance data including Note On, Control Change, and Pitch Bend
Fact L2 First instrument JB

Supporting — enrichment, not gating

MIDI Clock sends 24 pulses per quarter note so slaved devices can synchronise tempo to a master sequencer
Concept L2 First instrument J