Question on OSC /meters data

[kmitchell]

Has anyone worked with OSC /meters data? I'm trying to understand what the spec is saying.

/meters/1
ALL CHANNELS:
16 mono + 5x2 fx/aux + 6 bus + 4 fx send (all pre) + 2 st (post) + 2 monitor
-> returns one integer size value and 40 short signed integer values (16 bit) as single binary blob

I understand the 40 short signed ints are the 40 meter values but I don't understand what the 32 bit integer at the start of the blob is telling me.

Any guidance?

EDIT: The first 4x bytes (32-bit integer) is the length of the blob. In this case, it's actually the number of 16-bit signed integers in the blob, not the length in bytes.

[kmitchell]

Never mind. The first 4x bytes (32-bit integer) is the length of the blob. In this case, it's actually the number of 16-bit signed integers in the blob, not the length in bytes.

Has anyone worked with OSC /meters data? I'm trying to understand what the spec is saying.

/meters/1
ALL CHANNELS:
16 mono + 5x2 fx/aux + 6 bus + 4 fx send (all pre) + 2 st (post) + 2 monitor
-> returns one integer size value and 40 short signed integer values (16 bit) as single binary blob

I understand the 40 short signed ints are the 40 meter values but I don't understand what the 32 bit integer at the start of the blob is telling me.

Any guidance?

[kmitchell]

I'm still stuck on how a 16-bit signed integer translates to a meter value. How does -32768 to +32767 map to -oo to +10dB? I think it's a mental block. Does anyone have any code samples they could point me to?

[pvannatto]

I'm still stuck on how a 16-bit signed integer translates to a meter value

Are you sure those are not 32 bit floats? According to Patrick's X32 OSC Protocol doc (pages 16-19), the X32 meter results are floats and the X-Air DSP is based on the X32. Unfortunately, that is about the depth of knowledge that I understand, since I've never dealt with meter OSC commands.

[kmitchell]

I'm following this info from the spec doc:

/meters /meters/1
"returns one integer size value and 40 short signed integer values (16 bit) as single binary blob"

The "size" at the start of the blob seems to match the number of short ints I'd expect. I did figure out that the data is big-endian byte order since the size is '28 00 00 00' which is 0x00000028 or 40 decimal.

Is the meter values also big-endian? Hmm. Maybe that's the problem. Still don't know how to take the log of a signed number if it's negative. I need to go review my math lessons.

[pmaillot]

I found this in my files... Maybe it can help:

osc meter batches (all levels 16 bit signed short integers, resolution 1/256 dB):
0 (8) pre l, pre r, gate gr, comp gr, post l, post r, gate key, comp key; (single channel data)
1 (40) 16x ch pre, aux pre l, aux pre r, fx1 pre l, fx1 pre r, ... fx4 prel, fx4 pre r,
bus1 pre, ..., bus6 pre, fxsend1 pre, ..., fxsend4 pre, main post l, main post r, mon l, mon r
2 (36) 16x preamp in, 2x aux in, 18x usb in
3 (56) 4x (fx in l, fx in r, 10x fx state mtr, fx out l, fx out r)
4 (100) 100x rta level
5 (44) 6x aux out, main l out, main r out, 16x ultranet out, 18x usb out, phones l, phones r
6 (39) 16x ch gate gr, 16x ch comp gr, 6x bus comp gr, main comp gr
7 (16) 16x ch automix gr
8 (4) 4x dca (ch post)
9 (4) recorder in l, recorder in r, recorder out l, recorder out r;


Then, in some conversion for RTA on X32 and XR18, the OSC blob returns a set of 16bits ints representing meter values (for RTA). The conversion I have in one of the programs is just dividing the int (cast to a float) by 256., giving the dB value.
For example, a 32bit value of 0x008000c0 will represent two values, the first one being 0x8000 (or -128.0
after conversion), and the second one being 0xc000 (or -64.0 after conversion). Similarly, a 32bits value
of 40e0ffff will represent two successive RTA values of -31.75db and -0.004db, respectively.
Note: a short int value of 0x0000 (or 0.0db) means signal clipping occurred.

For X32, There's the even more exotic /meters/16 (Automix) that has different formats. The OSC blob starts with Big endian coded length, and all other values are little-endian so conversions can be faster for most (intel-based) systems. All data sent as little endian coded short ints. The first 44 32bits data are split to 2 shorts; Each short int value represents a floating-point level in the range [0, 1.0], by dividing the short int (converted to float) by 32767.0.
The 4 last 32bits data are 8 automix (channel 01...08) gains coded on successive shorts as Log2(value) * 256.

[kmitchell]

Wow! Thank you Patrick. A Lot of good info. I'll report back when I get it working. I've set up a test rig with a tone generator and signal scope for development.

[kmitchell]

Thank you again @pmaillot . I got the meters working in TouchOSC. Each reading is a 16-bit signed integer and the 2x bytes are swapped in the OSC blob. 'E3 A2' is actually 0xA2E3 (-23837) or -93dB.

It's interesting that the meter readings can be below -90db on the X-Air. For purposes of db-to-float, I just clamp the db value to -90 if it's below -90. -90 or -91 or -93 is insignificant for these meter readings.

I'll post my code and TouchOSC template when I get it cleaned up and commented.

[pmaillot]

Great! Yes, the meters' dynamics have a range of 128dB (-128->0).
Maybe one thing to validate is if the range has to be re-mapped after conversion to [-118...10] or if it actually is [-128..0]

[kmitchell]

Is that dynamics range for the X32 or XAir? Currently, I'm looking at /meters/1 data but I think I'll experiment with /meters/0 and /meters/2 today to get a better idea of the range.




EDIT: Also, every subscription request yields 200 OSC updates over a 10 second period. Doesn't look like there's any way to change that.