OSC reference

Connecting

UDP to port 8765. No handshake — send anything and you are registered as a client. Send /Unsubscribe/* to leave cleanly. Several clients at once is fine; each is identified by its address and port and keeps its own subscriptions.

ampOSC also advertises itself on the local network as _osc._udp under the name ampOSC, so a client that browses for OSC services can find it without being given an address.

Paths are case-insensitive on input, but the bridge always echoes canonical PascalCase — /Input/1/Level. Match replies case-insensitively rather than against what you sent. Every index is 1-based.

Message intent

Four intents, and the bare form is usually what you want.

/Input/1/Level ,f -6.0        set input 1 to -6 dB
/Input/1/Level                ask, and subscribe from now on
/Subscribe/Input/*/Level      subscribe without asking first
/Unsubscribe/Input/1/Level    stop
/Unsubscribe/*                stop everything

A path with a value is a SET. A path with no value is a GET, and asking also subscribes you — which is the shortest way to get a client in sync and keep it there. The explicit /Set/ and /Get/ prefixes do the same thing if your client needs them.

Subscriptions last until you drop them; there is no keepalive.

Two modes

Everything above describes subscription mode, which is on by default. The Enable Subscriptions switch in the app's OSC Server settings turns it off, and then the server floods instead.

A client written for one mode works unchanged in the other, but the traffic it sees is completely different — a surface that never subscribes is fully fed in flood mode and goes silent the moment subscriptions are switched on. If you are writing a client for other people to use, subscribe explicitly and it will be right either way.

Addressing

An index can be one channel, a range, a list, or all of them.

/Input/3/Level                one channel
/Input/1-8/Level              a range
/Input/1,4,5-8/Level          a list
/Input/*/Level                every input

So a single message addresses as many crosspoints as you like: /Input/1-48/Aux/1-12/Level is 576 of them.

Channel types

Counts are what each manufacturer's protocol document publishes, not what a particular model has fitted. Stereo types are their own path segment — /GroupStereo/1/Level — not a flag on the mono one.

Level, mute, name, colour

Name and colour are dLive and Avantis only. Neither SQ nor SQ+ carries channel names or colours in its MIDI protocol, so those addresses answer nothing there.

Sends

A send is the destination bus as a path segment under the source channel. There is no Send keyword.

/Input/1/Aux/4/Level   ,f -6.0     input 1 to aux 4, at -6 dB
/Input/1/Aux/4/Enable  ,T          route it
/Input/1/Group/2/Level ,f 0.0      input 1 to group 2, at unity
/Input/1/AuxStereo/3/Level ,f -3.0 to a stereo aux

Destination types are Aux, Group, FxSend and Matrix, with their stereo forms. Send levels use the same dB scale as a fader.

Two limits from the consoles. Avantis has no send routing — levels work, Enable does not. And on SQ and SQ+ an input cannot send to a matrix: matrix sources are LR, aux and group.

Pan

SQ and SQ+ only. Neither dLive nor Avantis exposes pan over MIDI. On the SQ pair it is available on inputs, groups, FX returns and the outputs — not on DCAs, mute groups or FX sends.

DCA and mute groups

/Input/1/Dca/3/Assign        ,T     put input 1 in DCA 3
/Input/1/MuteGroup/2/Assign  ,F     take it out of mute group 2

dLive and Avantis only. The SQ pair can mute a DCA and set its level, but membership is not in its protocol.

Assign or Enable

Two words that look interchangeable and are not. The rule is about what kind of thing you are switching.

Both take T / F. Every path segment is exactly its internal token name, so there is no lookup table to consult — the path is predictable from the thing it addresses.

Preamp

dLive only, and addressed by socket rather than by channel — 128 of them: 64 local, then two DX expanders of 32.

No Preamp/ sub-block: three parameters do not need one.

Filters and EQ

/Input/1/Filter/1/Freq   ,f 120.0    high-pass at 120 Hz
/Input/1/Filter/1/Enable ,T
/Input/1/Eq/2/Freq       ,f 1000.0
/Input/1/Eq/2/Gain       ,f 3.0
/Input/1/Eq/2/Q          ,f 1.0      octaves
/Input/1/Eq/2/Type       ,s "Bell"

Filters are their own indexed block, separate from the EQ — so a high-pass is Filter/1, not an EQ band. dLive has four parametric bands, numbered 1 to 4. Frequencies are hertz, gains are dB, and Q is bandwidth in octaves.

Type is a string: "Bell", "Lowshelf", "Highshelf", "Lpf", "Hpf". dLive restricts shelves and passes to the outer bands.

dLive only. Neither Avantis nor the SQ pair exposes EQ over MIDI.

Scenes and cues

/Scene/Recall    ,i 42     recall scene 42 — every console
/CueList/Recall  ,i 150    recall a cue by its position in the list
/CueList/Go                fire the standby cue    dLive only
/CueList/Next              advance                 dLive only
/CueList/Previous          go back                 dLive only

Recall is a bank plus a program change, which is the one control path every one of these desks shares — so /Scene/Recall works everywhere. /CueList/Go, /Next and /Previous ride the surface's user CC messages and are dLive only.

dLive and Avantis hold 500 scenes; the SQ pair holds 300. Recalling a scene at the desk sends the same message back, so a scene fired on the surface reaches every subscriber.

Cue lists differ. dLive has 2000 recall IDs but only on the Surface port. The SQ pair recalls cues by position and supports MIDI Show Control. Avantis has no cue list at all — scenes only.

MIDI Show Control

Its own family, and SQ, SQ+ and Qu.

/Msc/Go     [,i cue] [,f fadeSec]   both arguments optional
/Msc/Load   ,i cue
/Msc/Reset

/CueList/ is the surface's own cue-list navigation, on dLive; /Msc/ is the MSC protocol, on SQ, SQ+ and Qu. Two different things on different desks, which is why they are no longer both spelled /Cue/. MSC has no next or previous — those are not MSC commands.

Transport — read-only

What they are is a notification. Subscribe, and when an operator presses a transport button on the desk, ampOSC pushes the matching path to you. None of them carry a value.

/Transport/Stop
/Transport/Play
/Transport/FastForward
/Transport/Rewind
/Transport/Record
/Transport/Pause

/Transport/Start and /Transport/Continue are accepted as spellings of /Play, so an older client's subscription keeps working. New ones should use /Play.

CQ has no MMC at all, so nothing on this list ever arrives from one.

Surface controls

/Strip/1/Fader   ,f -6.0
/Strip/1/Mute    ,T
/Strip/5/Rotary/2 ,f 0.5
/SoftKey/3/Press ,T
/Ufx/Key         ,i 7
/Ufx/Scale       ,i 1

The documented consoles have 32 assignable MIDI strips each. Soft keys are Avantis and the SQ pair — dLive has none in its protocol. UFX is dLive, Avantis and SQ+; plain SQ has none.

Value types

Values are always engineering units — the number a sound engineer would read off the desk. Never a normalised 0-to-1 float. Each console encodes a fader differently, and ampOSC converts and clamps at the wire, so a client never sees a raw console value.

What each console does

Six families, and the OSC surface is identical on all of them — the path grammar never changes. What differs is which parameters and how many channels exist, which is why you should ask the inventory rather than hardcoding per-family availability. A path that is not supported is accepted and quietly does nothing.

Beta means not yet verified against hardware. Those paths are built from the published protocol documents and should be right, but nobody has proved them on a desk. dLive and Avantis are the proven paths.

Every number in the two tables — channel counts above, capabilities below — is read from that family's own published protocol document. Where a desk is configurable, the figure is the protocol's maximum rather than what a particular one has fitted, so the inventory is still the thing that bounds your paths.

Nothing meters. No published protocol reports audio level over the MIDI link, so no client can draw a meter from it. And on SQ, SQ+ and Qu the fader law is a console setting no message reports. ampOSC implements Linear taper only, so set those desks to Linear taper. dLive, Avantis and CQ each have a single fixed law and need nothing set.