OSC Sender: TCP vs UDP

[eight]

I am using the OSC Sender to send commands to hundreds of smartphones in the audience; the smartphones are using OSC UDP receivers. I noticed that not all of the devices receive the signals all the time. This should be expected as UDP is designed to be quick, but does not guarantee delivery.

TCP– based OSC signal, on the other hand should guarantee the delivery to all devices on the given network (I am using 255.255.255.255 multicast).

Is there a way in Isadora to send TCP–based OSC signals?

If the answer is NO, I would have to write an OSC proxy, converting UDP transport to TCP, which I would like to avoid to have another moving part in already complex system.

And while we are at it, is there a way to send midi data over OSC? My OSC receiver on device allows receiving midi data.

Thanks.

--8

[DusX]

I don't beleive so (not easily). This is something I have mentioned before (my DAW supports tcp OSC)

The TCP actors are very flexible, so it might be possible to roll your own.. but I can't give any guidance 

I do suggest entering this as a feature request though.

[eight]

@DusX Submitted a feature request.

Did you try to send MIDI data over OSC?

Thanks!

[DusX]

No, I have not. I would imagine you would need a 3rd party tool to convert+send.

[jhoepffner]

Hello,

You ask for two contradictory things

TCP is a secured point to point communication, you make a particular session between two IP points, so you send it until handshake from the receiver.

In UDP you can broadcast your message to all the potential receiver in the network, it's your purpose, I presume. You cannot do that with TCP.

The only solution, even with a third party software, would be to establish a session with each person in the audience, difficult to manage or you need a dedicated server, like a web server.

Jacques

[Marci]

Node-Red & websockets running independantly from Izzy can form an OSC buffer / repeater... These days I translate the OSC into JSON, and publish via MQTT as MQTT can be configured to cache, buffer and retransmit as well as rate limit (depending on your chosen MQTT broker and config).

[eight]

@jhoepffner I could do a multicast with TCP transport, given the addresses of all devices on the network. The protocol would look like this:

-- send an init UDP OSC multicast to all devices

-- once initiated the device would reply back, its address then can be obtained from the reply message

-- as the device IPs are coming in, a TCP based OSC sender would update its queue to account for all devices, which replied.

@Marci -- thanks for the node-red mqtt suggestion -- this may be the way to go to build this OSC proxy. Would you share a simple node-red flow, which talks to Isadora OSC sender and retransmits using mqtt?

--8

[Fred]

Just a quick question as far as I knew, OSC was strictly UDP, is there a TCP version of the spec? I had a look and saw a cinder lib that had something like that going on, but I did not see any official spec, I would be curious. I have TCP, but just my own messages to get the reliability, and also made a dodgy hand made receipt system for OSC over UDP.

Looking at your smartphone project I would guess timing is also pretty tight? @Marci is right on, MQTT will give you fast reliable results. If you run a periodic clock stream and timer in your app you can delay message execution to an upcoming tick and have great sync as well. You can also go for a tiny lightweight nodeJS, also super fast.

[eight]

@Fred this app is cinder-based, using the new OSC block. It supports UDP and TCP transport, which are almost identical in terms of use (TCP can't do multicast, and order of bringing up the server and the client is important). I don't know about the specs, but under the hood this block is based on c++ asio library.

I don't have a feeling of how unsynchronized the messages arrive to the devices, if they did arrive. By ear and a naked eye the arrived messages are in sync. Also, in the first show I have embedded the app into, reaching the destination at all is more important than reaching it in sync.

Node-red and its mqtt modules are node.js based. I have a solid experience with node, but the node-red flow diagrams operation and semantics escaped me in 5 minutes I spent yesterday after installing all that good stuff. Hence, having a basic flow example of how to wire osc and mqtt would be swell.

In the second show I am working on right now, I want to selectively control devices, this is where node-red proxy may become handy (it will keep the addresses of all devices and distribute the messages between them as needed). If not that, cinder's new osc block is great and I don't think I will have any difficulty coding the proxy in it. The only thing that stops me from jumping onto it, is that node-red may provide a much better configuration interface, which should be easily understood by the technicians in the field (once I build it), whereas cinder will require recompiling, until I figure out how to provide an easy off-line configuration.

--8