[OSC_dev] Managing different osc implementations

[Jeff Glatt]

> I'm wrong, but I don't understand why.
> What am I missing?

What you're missing is something that the Open Sound Control
specification doesn't explicitly state, which is the following:

1) It has nothing whatsoever to do with sound. Its name is a
misnomer, since there is not even a mention of sound in the
specification other than the use of the word "sound" in the
name of the protocol itself. It should really be called "Open
Data-packing", not "Open Sound Control".

2) All Open Data-packing... err... Open Sound Control...
does is specify a way to pack up a bunch (ie, any amount) of
data values (in the form of C primitives -- ie, 32-bit and 64-bit
ints, nul-terminated 8bit strings, floats, doubles, etc) into one
"block" of data. That's all it is. It doesn't define any other
standards. For example, it doesn't define any standard set of
messages for actually controlling sound. It doesn't even specify
how to exchange/deliver/save that block of data. For example,
one entity could transmit OSC messages over an ethernet
port, and another entity could transmit messages over a serial
port. Obviously, those two entities can't communicate with each
other without some sort of hardware adapter.

In other words, Open Sound Control does absolutely nothing
useful on its own. In order to do something useful, some
device/program that uses OSC therefore has to decide for itself:

1) What data values are put into any given OSC message,
and what those data values mean. In other words, each entity
has to come up with its own proprietary set of OSC-formatted
messages. Yes, each OSC entity can receive _any_
OSC-formatted message and pull the data values out of it. But
what does it do with those values? Unless it recognizes the OSC
path of that message as something it happens to know about,
it can't know what to do with the message. And of course, since
each entity defines its own OSC messages (ie, it own set of
recognized path strings), an entity can't know what to do with
a given message unless the sender is written to send only those
messages that are recognized. (ie, The two entities have to be
written to use the same set of proprietary OSC-formatted
messages).

2) How to transmit those messages -- over an ethernet port
using TCP, or maybe UDP, or a serial port, or a USB port,
etc.

Because there's no standardization for the above 2 design
decisions, that's why each OSC-enabled entity ends up with its
own set of proprietary messages (that just happen to include a
bunch of C primitive datatypes packed according to Open
Sound Control). So two entities can't do anything useful with
OSC unless they are specifically written to use the same set of
proprietary messages. (That's the part that you're missing. You're
thinking that OSC is more than what it is, in order to be practical
as a standard. It isn't. It isn't useful by itself. It _must_ be
combined with other standards, even if those additional
standards are proprietary, before it can do anything practical).

There have been some people who have attempted to come up
with additional standards (in the form of some standardized sets
of OSC messages, such as "Open Media Control", oscit, etc).
But none of these has found a foothold, because the fact of the
matter is that, all the people currently using OSC, seem content to
have their own proprietary sets of messages, and basically just
use OSC as some sort of "scripting language" (ie, a way to allow
some other programmer to write a utility that specifically works
with a particular proprietary set of OSC messages). For example,
the author of PD/Max doesn't care if some third party utility
works with every other app that does basically what PD/Max
does. He cares only that the 3rd party app supports PD/Max --
not his competitor's stuff. And the author of "Super OSC App" 
isn't worried about whether some 3rd party app supports
PD/Max. What he cares about is that the 3rd party supports
Super OSC App.

So OSC is not currently used for "interoperability". It's used only
as a way to pack up proprietary data.

I know what you're thinking. "Shouldn't an open standard be
concerned with interoperability? For example, what happens if app
A and B both define their own proprietary OSC message with
a path of /MyMessage, but the 2 messages contain entirely
different datatypes, and amounts of data?". Well, you'd better
hope those apps do really, really, really rigorous data checking
or they're going to do horrible, and perhaps destructive, things.
Actually, now that I think about it, given the existing implementations
and uses of OSC, I think the standard probably should be named
"Proprietary Message Data-packing".

If you found this message informative, then you may want to
look at my OSC library at:

http://home.roadrunner.com/~jgglatt/tech/easyosc.zip

The docs (and sources) for it will definitely help explain in more
detail what OSC is, and more importantly to you, what it isn't.