Exploring the network: OSC

Open Sound Control (OSC) was invented in 1997 by Adrian Fred and Matt Wright for the center of new music and audio technologies (the Center for new music and audio technologies CNMAT). It is evident, just by reading the name, that just like MIDI was a technology designed for the audio industry.
It was designed as a means of communication and optimization of networks between computers, sound synthesizers and other multimedia devices. Needless to say, OSC has come a long way from 1997. Currently, after the last revision of the specifications, being 1.1 in 2009, the protocol has been implemented in different sectors and has multiple uses such as robotics, web service, video and of course lighting control. Some propose a name change for one that reflects more its utility, like the one suggested in the NIME 2009 Paper: "Open System control" but after so long under the name of "Open Sound Control" its change will take a while.
OSC is a content format, also known as a protocol, in which the format of the message is defined. In summary, CSO does not define the linguistic semantics of the message, but rather indicates how the message should be composed. Which means, that unlike protocols like MIDI Show Control, where a "go" command is universally understood and standardized in different devices, in OSC the message can be composed, and usually is, of different standards. There is no predetermined content structure, which gives it great flexibility, allowing manufacturers to publish their own dictionaries and users to connect different mechanisms and applications. Sending signals, moving faders, collecting and changing information from one to another. OSC is a little gem.
Using a poor analogy, OSC could be compared to the conventional way of writing a postcard. With the address of the recipient in the top right, our message would begin with "Dear ..." on the left and finally signing with our name and a couple of kisses at the bottom of the paper. OSC tells us how to write the postcard, but does not dictate the content. OSC has multiple advantages because, if we move away from the postcard analogy, it improves in the field of organization and documentation, allowing manufacturers to create dictionaries so that users can obtain information from complex systems.
It is worth mentioning that OSC is classified as layer 6 or Presentation Layer entity. Which means that it is an independent way. Going back to the postcard analogy, OSC tells us the way we should write the message, but it does not tell us how it should be sent. In this article we will discuss the quality of OSC content format, but do not be alarmed, we will also discuss the use of OSC in the different protocols for sending information.

OSC messages
The format of the OSC messages can be divided into three parts: Address Pattern, Type Tag and arguments of those who are followed.

  • El Addres Pattern or pattern of address, is a unique code of patterns encrypted in UTF-8, that begin with the character "/" (sidebar) ex: "/ Eos / cue / 1 / 0.5 / fire." Sometimes called as namespace, usually written between sidebars, like URLs, where the structure of the system or devices work correctly, and where the parameters are located around a hierarchical tree, which we can call "address space. "The Address Pattern is simply a path from the hierarchical tree to the node.

message

  • La Type Tag is a string of characters that always start with the character "," (comma) followed by a sequence of characters that correspond exactly to the sequence of message arguments eg: ", ifsbt" All the characters located behind the comma are called OSC Type Tag and represent the data model of the corresponding argument.
OSC Type Tag Data Types examples
i Integer 18, 79, 21
f Float 3.8, 0.4, 36.9
s String King Kong, Eos Console, Hello World
b Blob (aka a byte array) 01001010 01011111 01001011 10111000
t Time Tag An OSC Timetag encoded in NTP Format

On the other hand, the argument may not be associated with any Byte, so the corresponding type tag will be 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

First of all

For proper use of OSC, knowledge of OSC Type Tag is not necessary, it is already generally used to distinguish what kind of information is going to be read, and to find some verification errors.

  • The arguments. Each CSO message can have as many arguments as none. In most cases, developers use the address pattern to document and describe the information within the arguments that must be followed.

Example 1:

Address Pattern = "/ time / out / hoursPerDay"

OSC Type Tag String = ", i"

Arguments (1) = "24"

Example 2:

Address Pattern = "/ cue / {cue number} / colorName"

OSC Type Tag String = ", s"

Arguments (1) = "green"

Example 3:

To extract the signal information (cue) from the ETC family ETC consoles, a message is sent with an "address pattern" "" / eos / get / cue / {cue list number} / {cue number}. " in turn it will return the OSC message.

Address Pattern = "/ eos / out / get / cue / {cue list number} / {cue number}"

OSC Type Tag String = ", issiiii ..."

Arguments (27) =

1 <- Index

B0BAW0A0-3BBE-888B-F61CA125D0B0 <- OSC UID

Houselights Out <- Label

3 <- Up Time

5 <- Down Time

0 <- Up Time Delay

0 <- Down Time Delay

...

second

OSC Bundles
Un Bundle or package is a sequence of messages, which allows the grouping of OSC messages in a same package that will be processed automatically by the application; in other words, it is as if all the messages grouped in a bundle were processed at the same time.
All bundles have their own timetag or time label, which specifies the time at which all messages in the package should be processed. You will have noticed that you can add a argument to the OSC message as a time label, allowing to program the exact time of the execution of the message, which allows us to predefine a sequence of events.
The OSC bundles offer the option of being thorough with the address pattern of the message, allowing the description of individual attributes to the elements of a bundle, but allowing the application to treat them as if they were one, unifying and processing them together as a package.
For example, an OSC bundle could consist of two OSC messages:

OSC Message 1:

Address Pattern = "/ fixture / 1 / pan"

OSC Type Tag String = ", f"

Arguments (1) = "270.0"

OSC Message 2:

Address Pattern = "/ fixture / 1 / tilt"

OSC Type Tag String = ", f"

Arguments (1) = "14.6"

In this example, the inclination attributes of the first element are described. By sending two CSO messages in the same package, each with an Address pattern that clearly describes their argument and avoids confusion.
However, the same information from the first element could be sent as an individual CSO message, but it could create confusion as to which accompanying argument refers to which attribute.

OSC Message:

Address Pattern = "/ fixture / 1 / focus"

OSC Type Tag String = ", ff"

Arguments (1) = "270.0"

Arguments (1) = "14.6"

Conclusion
In summary, we are faced with a "protocol" that offers us a creative, intuitive and extensive addressing scheme. Or to put it another way, before a dictionary of commands that allows the user to interact with the devices to carry out actions or request information from them. With just a look at the dictionaries of the families of Eos Cobalt y of Eos ColorSource, You can observe the amount of information that can be extracted and all possible actions. This allows users to create and use applications that can act as remote to see and interact with platforms, customize the documentation of archived mounts, not to mention the ability to create incredible interactive shows.

Surely you are asking yourself "How can I use this protocol?" Well, keep the parrot since we have not done more to start with a short summary of the protocol. In the rest of the series, we will explore how to implement it.

last

  • Later we will publish more related articles.
Go up