A Beginner's Introduction to OSC

[mark]

Daer All,

So a user in Utrecht was asking how to explain OSC to her students are not especially nerd-tastic. I came up with the following little metaphorical story as an introduction to what OSC is and how it works. Maybe that's useful to other teachers out there.

Best Wishes,
Mark

A Beginner's Introduction to OSC

The computers in an OSC universe are like a bunch of cities, where each software or hardware app on that computer is a house or apartment, and the OSC message is like a letter being sent to those locations via postal mail.
⁠
Like a physical letter you'd drop in a mailbox, the OSC "envelope" has an address that describes the intended receiver along and some information inside. There are two parts to the complete address: first is the IP address of the computer on which the receiver software is running (the city), second is the OSC address, which identifies a specific location within that computer (the address on the letter.)
⁠
So, the first step, to send a message to a particular computer on your local network, is to find out the IP address of that computer. If it's Isadora is receiving, you can find this out by opening the Isadora Preferences and looking at the bottom of the window. Here are more general instructions for macOS and Windows.
⁠
Let's say there is a computer called "Utrecht" whose IP address is 192.168.0.10. To send an OSC message to table four at 't Koffieboontje (an apparently great coffeeshop), we'd drop an envelop into the OSC postbox with the following address:
⁠
192.168.0.10
/Oudegracht/92/4
ffis
⁠
The first line is the IP address of the city (i.e., the target computer), and the second line where within that "city" you want that message delivered, starting with the largest geographic area first and going down to the smallest.
⁠
(Note that these addresses can only use the English letters and numbers, along with the '-' (hyphen) and '_' (underline) symbols; the space character, the characters #*,/?[]{} and non-English characters like ç, ø or ß are not allowed.)
⁠
According to the OSC specification, each envelope sent by the OSC Post Office can contain one or more of the following: an integer number, a floating point (real) number, or a string. It is up to the sender and the receiver to agree on how to interpret the contents – the order of the individual pieces of data is *not* part of the OSC spec. (Which is why each app or piece of hardware that transmits OSC needs to offer a specification of its own, telling you what the contents of the letter mean.)
⁠
Unlike a normal letter, the OSC envelope has an extra bit of information below the address that summarize the contents. Called "type tags" in the OSC specification, these give the receiver some information about contents of the "envelope."
⁠
Upon receiving the letter from the OSC Postal Service, if receiver sees 'iifs' written below the address as shown above, it would indicate that the "letter" contains two integers ('ii') followed by a float ('f') followed by a string ('s'). While Isadora doesn't display these type tags, like most software, it uses them to figure out how to read the data properly, even if it doesn't understand the particulars of what that data means.

[bonemap]

@mark

Reading through the informative OSC analogy, my thoughts immediately reflected on how TCP and UDP might fit into the metaphor and extend the explanation of the protocol. I did think of a messenger pigeon as a metaphor to represent UDP (fast but not always reliable), but I hadn’t settled on an analogy for TCP. Then I came across the following description:

“A short example to understand the differences clearly :  Suppose there are two houses, H1 and H2 and a letter has to be sent from H1 to H2. But there is a river in between those two houses. Now how can we send the letter?  Solution 1: Make a bridge over the river and then it can be delivered.  Solution 2: Get it delivered through a pigeon. 

Consider the first solution as TCP. A connection has to be made (bridge) to get the data (letter) delivered.  The data is reliable because it will directly reach another end without loss in data or error.  And the second solution is UDP. No connection is required for sending the data. The UDP process is fast compared to TCP, but the data is not as reliable: we don’t know whether the pigeon will go in the right direction, or it will drop the letter on the way, or some issue is encountered in mid-travel.”

I am happy to say that Isadora appears to train it’s pigeons well and provides an accessible and robust OSC solution through what I understand is the UDP protocol.

There is possibly a better analogy than pigeons and bridges.

Best wishes

Russell

[Skulpture]

@mark 

I have a presentation on this called "The ABC of MIDI and OSC" that I use for teaching - but I also use it for the Werkstatt. Happy to share it.

https://docs.google.com/presen... 

[DillTheKraut]

@bonemap

There is one more important aspect regarding TCP.

The pigeon analogy is fine for that as well. But the difference is, the first sender waits for a return of the pigeon with a confirmation of the reciever. If this confirmation doesn't come up after a certain time out, it sends the same message (with a new pigeon) again and again, until a timeout which ends the complete communication (brakes down the bridge). As one can imagine, this helps to ensure working communication, but is also a problem for steady, delay free streaming, as often new messages are not send until the last was a success or the reciever waits with processing the data, until all packages are complete.
This is why UDP/OSC often fails on unstable Wifi connections. If the message wasn't recieved in a certain time slot, it is lost without an error, not triggering the wanted event.
TCP and OSC does have in fact the same reliabilty for each send message (pigeon), but TCP works with a confirmation of success (and some other error checking mechanics), while UDP gives a sh... like fire and forget.

Interestingly your linked page shows this in the comparison chart, but misses the accurate desription in your qouted analogy.

[DillTheKraut]

Another aspect of UDP/OSC, which I've not seen in the other discriptions, is the easy ability for broadcasting messages.
Instead of sending the OSC command to a specific IP address, one can often use the networks broadcast address.

As for the Broadcast term, it describes the process of broadcasting packets to an entire subnet. (e.g: 192.168.1.001 to 192.168.1.254). As you see, the Address 192.168.1.255 here is spared out. This is the broadcast address of the used subnet. If you put this IP as the OSC recievers address, the messages will be fired to all IP Adresses e.g. devices in the network. This makes it easy to trigger multiple devices, with only one OSC message and therefore in Izzy, only one OSC send actor.