Problems with fields of OSC messages

1

Hi all,

I am implementing a patch that receive OSC messages from a program made in openFrameworks that track the coordinates of the joints of the human body. In its most simple form:

thisProcess.openUDPPort(9009);
(
OSCdef(\testOF, {
	arg msg;
    msg.postln;
}, '/ofxmp/handsW');
)

SC receives the messages:

[/ofxmp/handsW, h, 0, 1.9728881079229e-41, 1.8216880036223e-44, -0.074573159217834,...etc...

However, I realized that the field 1 and 2 are not what they should be, which is the tracking’s idetifier for each hand for instance, in other words msg[1] and msg[2].

Using Protokol to check the OSC messages outside SC, and I get the following messages:

ADDRESS(/ofxmp/handsW) INT64(14582) INT32(26) FLOAT(-0.025433855) FLOAT(0.08300941) FLOAT(0.028000904)...etc...

In this message, the field 2 has the value 26, which is the tracking’s identifier. At first I thought it was the type of the message, INT32. However, setting another OSC message that have the same type (INT32) from OF, which send the size of the screen, it show up correctly in SC. On he other hand, the field 1 of the type INT64, in supercollider is showed as h and in Protokol the value is the number 14582 .

Someone know what could happen, and how I can sorted out to get the tracking’s identifier in SC.

Thanks in advance

2

Hm, SC doesn’t have an int64 type, so it’s probably breaking there. If that’s the case, then it would need a backend (C++) change. And I’m not sure what the 64-bit integer should be converted into. Perhaps an array with most-significant word and least-significant?

It might be easier (probably easier), if possible, to modify the openFrameworks program to send the first value using a type that’s known to SC (e.g., split it into two 32-bit integers).

hjh

3

Thanks for replying, I think it is possible to modify the OF code, perhaps just filtering the field 1 because the important field is the number 2, which is INT32, the tracker identifier.

Thanks for the answer

4

Thanks a lot, it works. I cast the type to int32 in c++ and now I get the timestamp (which was in int64t) and the tracker identifier. I did not split the timestamp value in two int32t because I do not really use it in the project.

5

Ah OK – I see why it was int64.

For future readers, I think the way that a timestamp is expected to come into SuperCollider is as a timestamp belonging to a bundle. The OSC standard (IIUC) doesn’t support timesamps for messages, only for bundles.

If I format a timestamped bundle in Pd like this (500000 microseconds = 500 ms = 0.5 sec of what we call “latency”):

pd-timestamped-bundle
pd-timestamped-bundle470×311 16.1 KB

… then the timestamp does get passed into an OSCFunc / OSCdef as the time argument, and it can be used for correct scheduling.

OSCFunc.trace(true, true);

OSCdef(\test, { |msg, time|
	SystemClock.schedAbs(time, { msg.postln });
}, '/test');

// the OSC trace prints immediately: OSC responders fire immediately upon receipt
OSC Message Received:
	time: 1919.649223556    <<--- relative to SC's 'seconds' timebase
	address: a NetAddr(127.0.0.1, 54000)
	recvPort: 57120
	msg: [/test, 5]

// SystemClock.schedAbs pushes this a half second back, correctly
[/test, 5]

I also think SC’s OSC parser should not choke in this case – will log an issue.

hjh