OSC via TCP has no framing

Help, Support & Bugs
3

@Neurogami

Thank you for the summary and the corresponding links.

That’s exactly how it is right now, some apps/libs are compliant to the spec-1.0 (e.g. SuperCollider), some are compliant to the spec-1.1 (e.g. PureData), and some can do both (e.g. liblo)

Renoise’s default TCP-OSC server seems not to be compliant with any spec at all, though, which makes it useless.

SuperCollider

http://supercollider.sourceforge.net/

http://doc.sccode.org/Guides/OSC_communication.html

PureData

http://en.flossmanuals.net/pure-data/ch065_osc/

http://puredata.info/downloads/osc

liblo (lightweight OSC library)

http://liblo.sourceforge.net/

To summarize this thread here:

http://thread.gmane.org/gmane.comp.audio.osc.devel/1035/focus=1044

Best practices:

  • For datagram protocols (e.g. UDP), send the raw OSC packet.

  • For reliable stream protocols (e.g. TCP, USB), use spec-1.0 and send the OSC packet prefixed with its int32 size

  • For unreliable stream protocols (e.g. serial), use spec-1.1 and send a SLIP (double)encoded OSC packet

SuperCollider does it right, IMHO, by using spec-1.0 for TCP.

PureData provides only one function for streaming OSC packets, not discrimiation between the underlying transport channels (e.g. TCP vs serial).

As PureData is widely used to interface to sensors and microcontrollers via serial lines, they choose the spec-1.1, I guess. OSC via TCP is just not that common.

liblo supports both framing approaches as it is frequently used to interface to both :slight_smile:

Renoise in turn only processes raw OSC packets sent via TCP (I actually had to write a tiny TCP app to find out why none of my OSC packets were processed) which is neither compliant to spec-1.0 nor spec-1.1.

I thus would opt to use spec-1.0 (int32 size prefix) for Renoise, but I would be equally happy with spec-1.1.