Hi Rob,
The OSC protocol is actually at layer 7 of the OSI model.It is encapsulated inside UDP packets, and UDP is a layer 4 protocol. The TCP/IP model is a simplified version of the OSI model in which layers 5-7 are squashed together into a single actual layer, which we call layer 7 to avoid confusion (instead of calling it layer 5). As a result, OSC is layer 7. There are similarities with the HTTP protocol (used for web browsing) here - HTTP does not define at all the HTML language, and is used to fetch images and documents that are non-HTML. HTTP itself is pretty protocol agnostic. It can also pass arguments in GET and POST requests that are quite similar to the data types in OSC. The reason for OSC to exist rather than using HTTP is that guaranteed delivery is not needed - if you are sending something more automation-oriented like a smooth curve and one single data element is missed, it isn’t the end of the world, you can simply get the next one. The guaranteed delivery with TCP based protocols like HTTP leads to overhead since then you need ACK packets, and if the computer misses an event you may not want that event to be triggered a second late because the computer realized it missed the value.
As you say, it is not a perfect analogy regarding email, because email was never intended to have anything to do with sound, but OSC has the word “Sound” directly in its name. Although I get your point regarding semantics, that is generally only possible when it is a fixed prefabricated device or piece of software on the far end that has a predefined “list” of such things, a kind of “OSC API”.
Instead, the standard for live electronics performance (or at least near to it) is to use a product called Max, which is basically a visual programming environment. Each piece is a different program and can be created from the ground up from scratch (although I tend to start with a “template” that I built to save some repetitive work). Because the far end is being coded by me in this case, the addresses that I select are arbitrary, and there are many different things that different people do. I generally tend to use OSC in quite a simple way - when you hit a rehearsal, you get an OSC Message like /rehearsal 0, /rehearsal 1, /rehearsal 2, (address “/rehearsal” with an integer value) and those messages trigger Max to activate those rehearsal numbers and do various musical things like turn certain effects on or off or activate bed track sounds. Because I have a tendency to use OSC for just short simple messages like that instead of firing raw continuous data, MIDI can be a workaround if I map say a MIDI CC to the rehearsal input, and that is what I do right now. However, OSC is simpler and tends to “just work” as long as your address and port are correct and your firewall is adjusted or switched off, and makes it easier to use separate computers for separate tasks. Also, using MIDI limits me to 7 bit values unless I jump through hoops or use something weird like pitchbend to convey the data, and some long pieces may have more than 127 discrete trigger points.
A lot of people work with OSC in different ways than I do. For instance, my teacher prefers to store more of the data in the notation program (like the screenshot above) for more direct control of the sonic environment, and to allow setting the sonic parameters from the same program as the traditionally engraved notes. This method has a lot of appeal as well if the program supports it, since traditional engraving does not really show live electronics events, and this way the notation software has more of a direct representation for what is happening in the live electronics.
One way that I could envision OSC being integrated into Dorico is almost like MIDI controller lanes. You would define one or more OSC listeners in the software (remote IP and port to send the data to) plus OSC address/type combinations associated with those listeners (defining an address and setting a data type for that address to either string, integer, or float). Then you would get something resembling a CC lane for that address/listener combo, and the style of lane would depend on the chosen data type for that particular OSC address. For strings obviously there would be no automation, you would simply add the string value you want to send at the correct point in the timeline. Integer and float could use similar automation controls to MIDI CC, but with possible value ranges that matched the data type. It is really quite similar to MIDI CC except with greater resolution, the ability to choose between integers and floating point, and support for strings. CC# is the equivalent of OSC address, except OSC addresses are arbitrary strings where you can use slashes to denote heirarchy. So OSC is really more a kind of “MIDI CC’s 2.0” in many regards rather than being something completely alien.
