SpQ15 OSC

OSC (late '90s) is an alternative to MIDI (1983), hasn't caught on super quickly yet

Yamaha DX7-first MIDI keyboard--we have one down in the classic lab--FM synthesis based

MIDI is designed to handle 8-bit samples, not a lot of data or very rich data.  OSC is designed to handle 32-bit numbers.

Here's the OSC specification site:
http://opensoundcontrol.org/spec-1_0

transport-independent message system--the OSC message is the content, but what's the container it travels in?  There's 2 basic transport protocols, UDP and TCP/IP.  The internet uses those guys.  In the case of the internet, the messages are HTTP messages traveling over a TCP/IP connection.  OSC typically uses UDP.  Main distinction between UDP and TCP/IP is that UDP just sends the data, doesn't care if the other side receives it, whereas TCP/IP waits for acknowledgement that data was received.  A little bit of overhead/latency with TCP/IP, but it ensures both sides know the message was sent and received.  You can send OSC messages on TCP/IP, or USB, or MIDI, but if you want quicker response you can use UDP.

In Max, there's an object udpsend and udpreceive that defaults to sending/looking for OSC messages.

MIDI has a message structure and a hardware specification.  OSC doesn't have a hardware specification.

Data types: In memory, zeros and ones could mean anything.  The computer has to know what it's looking at/for.
float32 tells it to look for a floating point number--first byte tells it where the decimal point is, next three bytes tell it the value
int32 looks for an integer--signed & unsigned (uint32), signed being negative and positive, unsigned being zero on up
char 8-bit, typically unsigned--in Jitter, often used for RGBA, with each component being a char

big-endian is where the largest, most significant digits are on the "left" and the least are on the "right"--Motorola uses this, whereas Intel does little-endian--for OSC, it has to decide to interpret as big-endian or little-endian, it prefers big-endian

in a string, the null ASCII character let's it know the string is done, literally a value of 0--the null character as typed for OSC is \0

the OSC-blob allows you to package another file, say a TIFF, or a PNG, or a JPG, or any file, you enter the size of the blob in bytes using the data type int32--then the blob is some arbitrary number of bytes, but the OSC-blob message tells you how big the blob is--you can use an OSC message to carry anything, using a blob--he doesn't know if Max supports blobs

OSC Packet consists of message and size.

OSC Packet can be either a Message or a Bundle.  The first byte tells it which of those it is.

OSC Message consists of: Address Pattern, Type Tag String, 0+ Arguments--Address, Type Tags, Args

Address Pattern and Type Tags are both OSC Strings

Args could be whatever, however many of them

Address identifies what kind of message it is.  For example, in Jordan's program, /faster.  You could have more slashes and create subcategories of messages, too.  In MIDI, there are fixed message types, like "noteon," but in OSC you have to create the message types yourself, and they can be anything.

Type Tags are a comma "," followed by a sequence of characters corresponding exactly to the arguments to follow.  If there are no arguments, you still need a type tag string: ",\0\0\0".  There are four possibilities: i => int32, f => float32, s => OSC-string, b => OSC-blob.  There are also, less standard possibilities, listed in the specifications.

In Max, it's taken care of automatically.  In programming X-code yourself, you have to include it.