Behringer X32 OSC meters: subscribe with /batchsubscribe and /renew to get live level data

See why X32 sends faders and mutes after /xremote but no meter data; fix it: subscribe to /meters with /batchsubscribe and renew via /renew to stream levels.

Behringer X32 OSC meters: why you see faders and mutes but no level data — and how to fix it with a proper meter subscription workflow.

Problem overview

You have a stage-facing indicator app that reacts to mixer state: livestream on, channel mute, and similar cues. The next step is to flag channels with zero input before gate, so performers instantly know a mic isn’t actually passing signal. You already send /xremote and successfully receive real-time updates for faders, bank changes, and mutes for about ten seconds. However, attempts to read meters directly — with variations like /meters/1, /meters/6, and /meters/6 5 — produce no data. In practice, anything starting with /meters doesn’t yield a packet from the console.

Minimal command sequence that illustrates the issue

The following command flow shows the typical behavior: state updates arrive after /xremote, but meter requests don’t respond.

/xremote
/meters/1
/meters/6
/meters/6 5

Why this happens

Fader, mute, and bank changes are pushed after /xremote, but level data is not part of that burst. Meters require explicit subscription. Without it, the X32 won’t send meter payloads, and raw /meters requests won’t elicit a response.

The fix: subscribe to meter addresses and renew periodically

To receive meter data, first subscribe to the target meter path using batchsubscribe, then keep the subscription alive by renewing it regularly. The sequence below uses an alias and the /meters/1 address as an example. After subscribing, send a renewal in intervals under ten seconds.

You may need to subscribe to a meter OSC address, using the batchsubscribe command, e.g.: /batchsubscribe ,ssiii mtrs /meters/1 0 0 0. Then, every < 10 sec send: /renew mtrs.

Command-level sequence:

/batchsubscribe ,ssiii mtrs /meters/1 0 0 0
/renew mtrs

Application-oriented flow with clearly named helpers:

// Pseudo-code: dispatch OSC, then schedule renewals under 10s
function oscSend(addr, typeTags, ...args) { /* transmit OSC packet */ }
function schedule(task, ms) { /* run task after ms */ }

// tell console we want meter updates for /meters/1
oscSend("/batchsubscribe", ",ssiii", "mtrs", "/meters/1", 0, 0, 0);

// keep the subscription alive
function keepAlive() {
  oscSend("/renew", ",s", "mtrs");
  schedule(keepAlive, 9000); // renew in < 10 seconds
}

keepAlive();

Note that while this subscription pattern works, it’s also been observed that the lack of meter data wasn’t caused by batchsubscribe itself. Nevertheless, the approach above reliably enables meter streaming and aligns with the behavior you’re seeing.

Why this matters

For backstage and on-stage UX, silent failure of meter polling looks indistinguishable from “no signal.” Without a proper subscription, your indicator app can only reflect control state, not live input levels. Once meters are streaming, your logic can confidently flag channels that sit at 0 dB pre-processing, making it immediately clear when a mic isn’t actually open.

Takeaways

If you’re getting state updates after /xremote but no level data, treat meters as a separate stream that requires its own subscription and periodic renewal. Subscribe to the relevant /meters path, keep it alive with /renew just under the ten-second mark, and your indicator layer will have the level information it needs to warn performers when a channel isn’t passing signal.