Just the Best Parts: Open Sound Control - Chapter 2.01

The finished, cleaned-up, copy-edited version of this book is available for purchase in PDF, mobi, and epub formats. You get all three formats when you buy the book. Plus, the paid version is where updates are made and contains content not available in the Web version.

Buy it now and get the most recent content. »

 Whence OSC 9  

OSC Technical Details

You can read the Open Sound Control 1.0 specification at http://opensoundcontrol.org/spec-1_0.

There’s no benefit to repeating every detail here. Instead, this section will smooth out the sharpt nerd edges to put the important parts of the specification in practical terms.

OSC is described as a “transport-independent, message-based protocol”. What does this mean in human-speak?

Well, imagine you are looking to have a party, and want a band to perform. You announce this, and tell people that they should get in touch with you, and that should tell you if they are interested, indicate the dollar amount of what they expect to be paid, and provide a phone number of who to contact in order to follow up.

In other words, you want people to send you a message with the following information:

You probably don’t care if you get these messages via E-mail, or postcard, or hand-delivered on a papyrus scroll.

This indifference to the details of how the information gets to you is the “transport-independent” independent part of OSC. Of course, whatever method is used needs to be something you can actually handle, and the same is true for OSC, but the OSC specification doesn’t say that OSC message have to be sent in any particular way.

The presumption is that, just as with people sending you messages in response to your request, people using OSC will work out a way that all parties can understand. (We’ll see later on just how that happens in practice.)

While you’re looking for a party band and reading these messages you’re going to be looking for the particular information you requested. You expect to find, someplace in the message, those three items of interest.

Us humans are really good at pulling out out information from a variety of content in assorted formats. Machines, less so. It’s rare that you can just throw stuff at a computer and it will know exactly what you mean.

If you were expecting to get a large number of replies to your request you might want people to respond using a consistent format. You might require people to follow each of your questions with the answer on the next line, all by itself. Or, since you know the questions, you might simply ask people to respond with just the answers to your questions, separated by commas, like this:

Yes, 1000, (212) 555-1212

Then, like a machine, you could process the responses quickly.

Computers pretty much have to follow pre-defined message formats. Even in cases were a machine could pull out useful data from haphazard messages, the use of a predefined message format makes things go so much faster.

The OSC specification gets into a fair amount of detail about the format of these messages. Unless you are writing software to send or receive OSC message, though, you do not need to know these details.

You don’t need to know the deep mechanics of an OSC message, but you’ll want to know, at a higher level, what sorts of stuff can go into an OSC message.

Next page

comments powered by Disqus

The finished, cleaned-up, copy-edited version of this book is available for purchase in PDF, mobi, and epub formats. You get all three formats when you buy the book.

The paid version is also more current and has additional content not available in the Web version.

Buy it now and get the most recent content. »