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.
First, some terminology. The thing (be it some device, or some software) that sends an OSC message is an OSC client. Whatever is receiving those messages is the OSC server. This may or may not seem backwards to you, but in any event that’s how the terms are used.
When people write about OSC messages, for example to describe what messages some particular software sends or understands, they use a few variations on something that looks like this example:
/some/message/pattern i, s, f
You will also often see it written like this:
The part with the slashes, that looks something like a Web address, is called the message pattern.
The stuff that comes after the message pattern are, technically, tag types. When an OSC client sends a message there needs to be a message pattern, and there may also be some additional information or data as well.
The OSC specification says that additional data can be text or a number. (The specification is actually much more precise than that, but this will do for now.)
Many people write out their OSC messages using single-character tag-type notation. The OSC specification defines a very small set of tag types. It accepts, though, that in real-life various OSC systems may implement non-standard tag types so it defines a set of type tags for dozen or so kinds of data that can be sent as part of an OSC message.
These are the official tag types:
|OSC Type Tag||What kind of data|
For the non-geeks (quite possibly everyone) reading this, some explanation:
Integers are numbers, without any decimal point. They’re sometimes called “counting numbers”, and they’re what you use when you, well, count stuff, or ask for some specific amount of something, as in, “I’d like 429 cerulean-blue marbles, please.” Floating-point numbers have a decimal point, so they can express fractions. These are the kinds of numbers you see on, for example, a credit card receipt, where they indicate (in North America, at least) dollers and cents; the cents are fractions of dollars. “$1034.94 for the marbles? That’s crazy!”
String is geek talk for one or more characters, also often called text. Or, sometimes, just characters. “These” “are” “all strings.”
A blob is not some jelly-like thing but a binary large object. This is a way to package up a whole bunch of a lot of stuff as one thing. The binary aspect means that the data being sent are packaged up in a way that makes it easy for a computer program to figure out; unlike strings or integers or floating-point numbers you can’t just look at it and know what it is.
It some cases it may be helpful to know all the gory details, but mostly you don’t. This is because you’ll be using some software or tool to manage the sending and receiving of OSC messages, and in some cases entering the values to send or the address patterns to use. You will more likely be struck repeatedly by lighting after winning the lottery a few times than have to craft your own OSC blob. If your numbers are too big or too small, the software will yell at you.
(I’m lying about that last part. There’s a lot of software that, when given the wrong data, just fails to do something sensible. Often with no indication about what you need to do to make things right. The solution, though, rarely requires a detailed understanding of the OSC message format, but instead figuring out the quirks of the application you’re using.)
The bottom line is that there are a few absolutely required things any OSC setup needs to handle, and a dozen more that are likely to be available.
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.