Is the byteCount in Byte array returned from "/vcs,b" also big endian?

Question

In working through Kyma's OSC widget changes in the VCS, I am able to see /vcs,b byte array returned over OSC in my Processing sketch. I'm attempting to convert these into 32-bit floats to see the int_id0, float_value0 pairs, but I'm having a hard time understanding which bytes belong to what pairs.

For example, the Sound "Random Global Controller" has four widgets (BPM, Max, Min, Random).  The /vcs,b array is 24 bytes long. Example print-out of byte array below.  Is the byteCount just byte[0] / 8??  Or is this also a 32-bit number?  24 bytes only gives me three pairs for 32-bit numbers so I was just using byteLength to determine pairs. ("byteCount" is term referred to in the documentation. ref: http://www.symbolicsound.com/cgi-bin/bin/view/Learn/OpenSoundControlImplementation)

Second, my conversion seems to be a bit off. I have a generic byte converter but I'm getting way larger values than the widget concreteEventIDs.  For this example, when I printed out the byte array, my concreteEventsIDs are: 3145732, 3145731, 3145730, 3145729.  My conversion returns ints much much higher than these IDs for pairs 1 and 2 (796287859 and 744620032 respectively), even though 3 is correct (3145729), which is the ever changing !rando fader.

public static int packI(byte b1, byte b2, byte b3, byte b4) {
  return ((0xFF & b1) << 24) | ((0xFF & b2) << 16) | ((0xFF & b3) << 8) | (0xFF & b4); 
}

My end goal is to acquire VCS values so I can send them off to Wekinator to integrate some ML. Thanks all!

Byte array snap-shot (24 bytes long)

[0] 47
[1] 118
[2] 99
[3] 115
[4] 0
[5] 0
[6] 0
[7] 0
[8] 44
[9] 98
[10] 0
[11] 0
[12] 0
[13] 0
[14] 0
[15] 8
[16] 0
[17] 48
[18] 0
[19] 1
[20] 63
[21] 3
[22] 77
[23] -60

Answer 1

It looks like your Processing sketch is translating the entire OSC string into bytes.  In other words,

'/vcs' in terms of bytes would be  #[47 118 99 115 ]

',b' in bytes would be  #[44 98 ]

The first real information is in your line [12]-[15] telling you that the data (datum?;) is 8 bytes long.

After that, it is telling you that only one of the faders changed in value (probably !Random).

[16]-[19] is Event ID (0x300001) = 3145729

[20]-[23] is the value, which is 0.512905 in decimal.

Either you could write something in Processing to parse the message and unpack it for you, or if you know you will only be receiving messages of that form, you could ignore the first 16 bytes of each message since that is just the address part of the OSC message itself.

Comments

Thanks!  Unfortunately, oscP5, Processing's OSC library can only get byte arrays as a single group, whereas Strings, Ints, Floats can be parsed separately from the OSC address. I think this is how I initially got confused.  The second idea, ignoring the first 16 bits is the way to go.  I can still check the Byte array length to identify how many pairs I have, or use bytes 12-15.  Either way, I'm in a position to move forward.

Thank you!