What is OSC?

Thanks for mentioning oscRFR!

oscRFR is a Programming Remote developed specifically for EOS.   It is now available on iOS and Android.   We even have a Lite Version of the Android App out today!   The purpose of oscRFR was to utilize all of these great OSC features we now have with EOS and make the most complete programming remote available.

Other options for sending OSC commands to the EOS include :

TouchOSC - this is the simplest program and their are a number of nice templates available.   It is very affordable - but pretty limited in what it can do.    

Lemur - Lemur is another midi/osc Layout program for iOS and Android.   It's a bit step up from TouchOSC - you can do a lot of scripting in Lemur but it can be quite complicated.

OSC Widgets is a super cool free app from the developement team at ETC.   It allows users to create small OSC tools that work on Windows and Mac.   

A bunch of fun OSC related Apps can be found on GitHub - 

OSC Workshop Handout (The Gritty Details)

What is Open Sound Control (OSC)?

OSC is a content format often referred to as a protocol that allows communication between computers, consoles and multimedia devices that have been optimised for networking, but it is only a protocol in the weakest sense in that it defines a message format. Simply put, OSC does not define the semantics or language of a message it only states how the message should be composed.

"What is the message format then?! And what does that mean?!”

OSC doesn't define semantics or language. This means that unlike protocols such as MIDI Show Control where a 'Go' command is universally understood, In OSC a 'Go' command on a Electronic Theatre Control's Eos Console has an address pattern something like "/eos/key/go" and on Figure 53's QLab Software its "/go", both written in American English. There is no set structure for any such commands, which gives a wealth of flexibility at the expense that native cross device or application communication requires a collaboration between manufacturers.

Inter-application communication is of course possible though. With the help of parsers/formatters such as ETC's OSCRouter to make sense of the different semantics and languages across applications, address patterns and attribute can be translated.

The format of a OSC message is broken up into 3 parts - An Address Pattern followed by a OSC Type Tag String followed by zero or more Arguments.

A address pattern is a string of ASCII characters beginning with the character "/" (forward slash) e.g “ /eos/cue/1/0.5/fire”

A OSC Type Tag String is a string of characters corresponding exactly to the sequence of arguments in the message. e.g “ ,isfbt ”

A argument is any of the following data types:

An argument can also have no bytes assigned in the argument data, at this point the Type Tag corresponding to the argument is used to define the meaning.

For a typical OSC application knowledge of the OSC Type Tag is not necessary by the user. The OSC Type Tag is generally there for an application to know what type of data it's about to read and perhaps some error checking.

Each OSC Message can have multiple arguments of varying types or none at all. In most cases developers use the address pattern to describe what the information is that is being sent and the arguments are the actual values.

Example 1 - /eos/out/event/sub/<sub number> = <uint32: 0=off, 1=on>

Address Pattern = /eos/out/event/sub/<sub number>

OSC Type Tag = i

Arguments (1) = 0 or 1

Example 2 - /eos/out/get/version = <string: X.X.X.X.X.X>

Address Pattern = /eos/out/get/version

OSC Type Tag = s

Arguments (1) = X.X.X.X.X.X

Example 3 - /eos/out/get/patch/<channel number>/<part number>/notes = <uint32: index> <string: OSC UID> <string: notes>

Address Pattern = /eos/out/get/patch/<channel number>/<part number>/notes

OSC Type Tag = iss

Arguments (3) = index, string, string

History

1997 - OSC 1.0

Tom Wright and Adrian Freed from the Centre for New Music and Audio Technologies Department of Music, University of California, Berkeley introduced Open Sound Control 1.0 to the world.

“a new protocol for communication among computers, sound synthesizers, and other multimedia devices that is optimized for modern networking technology. Entities within a system are addressed individually by an open-ended URL-style symbolic naming scheme that includes a powerful pattern matching language to specify multiple recipients of a single message. We provide high resolution time tags and a mechanism for specifying groups of messages whose effects are to occur simultaneously”

2009 - OSC 1.1

After years of experience and  implementations of the protocol out in the field from users in both the New Interfaces for Musical Expression (NIME) Community and Creative Arts Industries OSC gets updated to 1.1 to provide a clarifications regarding the role it has in application architectures, more specific recommendations for optional features, new data types and a small change to the pattern matching syntax as well as a important change to the framing of OSC messages when using stream protocols such as TCP, called SLIP (RFC1055)