Re: OSC Reply Format

[Gabriel Rives-Corbett]

Sorry to double post, but further investigation (sending a "/workspaces" command) shows me that the reply is actually a valid OSC message (using OSC string formats and a variable list), however the message has only one string variable which is the JSON response, is that one variable reply consistent across all reply messages?

On Friday, June 7, 2013 12:25:23 PM UTC-4, Gabriel Rives-Corbett wrote:

Hello,

I've implemented OSC over TCP using double ended SLIP as specified by OSC 1.1.  However, when I read a reply back from QLab it seems as though it is just a standard string being sent back, not a properly formatted OSC message?  For example, I sent the OSC Message "/version" and instead of the first character that I received back being SLIP_END it was '/', with the rest of the message following.  Wireshark revealed that the message was suffixed with SLIP_END.  Is it the expected behavior that QLab does not use doubled ended SLIP?

Thanks,

Gabe

[Christopher Ashworth]

Hi Gabriel,

On Jun 7, 2013, at 12:25 PM, Gabriel Rives-Corbett <ga...@gabecreative.com> wrote:
>
> I've implemented OSC over TCP using double ended SLIP as specified by OSC 1.1. However, when I read a reply back from QLab it seems as though it is just a standard string being sent back, not a properly formatted OSC message? For example, I sent the OSC Message "/version" and instead of the first character that I received back being SLIP_END it was '/', with the rest of the message following. Wireshark revealed that the message was suffixed with SLIP_END. Is it the expected behavior that QLab does not use doubled ended SLIP?

Back on May 19th Josh Senick brought to my attention that our outgoing messages were using a single END version of the SLIP protocol, not the double END required by the OSC 1.1 spec. I've just fixed that and it will be fixed in the next update.

-C

[Christopher Ashworth]

Hi again Gabriel,

(As I belatedly return to respond to all these OSC questions as once…)

On Jun 7, 2013, at 12:40 PM, Gabriel Rives-Corbett <ga...@gabecreative.com> wrote:

> Sorry to double post, but further investigation (sending a "/workspaces" command) shows me that the reply is actually a valid OSC message (using OSC string formats and a variable list), however the message has only one string variable which is the JSON response, is that one variable reply consistent across all reply messages?

Yes. The reply format can be found here:

http://figure53.com/qlab/documentation/osc-api/#reply-format

There have been some requests (e.g. from Andy Leviss) to add some options for reply formats, e.g. to provide a simpler reply for embedded devices or clients where decoding both OSC and JSON on incoming replies is not trivial. I think that's legit and interesting, just haven't had time to put anything in to place.

-C

[Christopher Ashworth]

I should mention, for the folks who were encountering problems because QLab wasn't using double END SLIP:

It shouldn't have caused problems when receiving messages; if you're requiring two END bytes in a row, this is fragile, as the whole idea is that it should work with either a single END or a double END, but it doesn't strictly matter. The double END clears out any cruft that might have preceded the message. Getting two in a row isn't something you should necessarily expect, but if you do see it, it should produce a no-op operation in your code.

(For anyone using the F53OSC framework, which has now been updated with these fixes, you don't need to worry about code written prior to this change because it did handle the case of receiving double END messages as a no-op.)

Best,
Chris