What is OSC?

Good question! I've noticed a fair amount of confusion on the forums as to what OSC is. Many people confuse apps that use OSC with the protocol itself.

So what is OSC?

OSC (Open Sound Control) is a protocol for communication between devices. It's a specification which allows devices to talk to one another in a standardised way. That said there is a great deal of flexibility in the protocol.

TouchOSC is not OSC!

So what is TouchOSC? TouchOSC is an app which uses the OSC protocol to send OSC messages. These messages can be formatted to talk to a wide range of OSC compatible devices. This makes TouchOSC ideal to create your own remote for Eos or any other device. oscRFR is another great example but this is directly aimed at Eos control.

What else can OSC be used for?

OSC can be used for many other purposes. Triggering and synchronisation (think MIDI Show Control). Mapping sound information to lighting/video parameters. Handing patch and show information between documentation software and a device. The list is endless.

Hopefully this will be a help to some users!

Parents
No Data
Reply
  • 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:

    Data Types Examples OSC Type Tag String
    Integer 18, 79, 21 i
    Float 3.8, 0.4, 36.9 f
    String

    King Kong, Eos Console, Hello World

    s
    Blob (aka a byte array)

    01001010 01011110 01001011 10111000

    b
    Time tag

    An OSC Timetag encoded in NTP Format

    t

    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.

    OSC Type Tag Meaning
    T TRUE
    F FALSE
    N Null (aka nil, none)
    I

    Impulse (aka “bang”, used for triggers, This type was named “Infinitum” in OSC 1.0.

    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)

Children
No Data
Related