On May 3, 2005, at 8:29 AM, david tay wrote: Short description Open SoundControl is a new protocol for communication among computers, sound synthesizers, and other multimedia devices that is optimized for modern networking technology.
Question Will Apple be making this available as a system wide service in CoreAudio or would this initiative remain a third party opportunity?
OSC is interesting but it isn't clear how we could specifically take advantage of it in a way that is useful. There are already toolkits available for adding OSC to your app. What value do you think we could add beyond that? Since I have been a fairly heavy user of OSC myself, I am also aware of some of its limitations. Here are some of my thoughts:
OSC's open ended-ness means there is no standard way to do things that MIDI does -- even simple things like play a note. This is a good thing for experimenters because you can do "anything" but it leaves interoperability undefined. Even if the various proposed query systems were adopted so that a program can discover the commands available on a remote system, there is no way for a program to automatically know what those commands do. A program cannot automatically figure out how to play a note on a remote system. Thus interoperability would be limited to systems with known address spaces. That makes OSC less useful than MIDI for most commercial apps.
Though there are proposals for clock synchronization schemes, none has been adopted.
OSC is an RPC mechanism, but it does not define or give conventions for some of the basic things provided by other RPC systems such as how replies are matched to the commands that were sent, or how to identify who to reply to (For example, the sender may be a resource behind the IP address, so the IP address and port may not be sufficient). The format is not currently able to express graphs of data, only a single flat list. Of course this is already more than MIDI, but if you are going to make something open ended then it should be able to express data in as flexible a way as in XML-RPC, for example.
OSC does not separate the name of the remote resource from the name of the operation to be performed upon that resource. They are both combined in the OSC command address. The name of a remote resource is a combination of its IP address, port, and part of the OSC address. More abstract RPC systems make the resource address opaque so that you needn't be concerned whether that resource is located in the same process, in another process, or on another machine. Because the resource address and command are intertwined in OSC, it is not as simple to add that abstraction layer without adding obfuscation.
Since OSC was proposed, other concurrent communication schemes have been proposed and though not specifically meant for audio, may ultimately be more suitable. (Some problems with OSC have been solved in Roger Danneberg's Aura. The Erlang programming language is also interesting in how it abstracts services and handles failure.)
--- james mccartney -- apple coreaudio
|