There might be good reasons to use OSC, but it's not the only way to send and receive messages. You can use the FUDI protocol, which is already included in PD. The netsend and netreceive objects, along with the pdsend and pdreceive command line utilities, works with UDP or TCP. Its only purpose is to send and receive lists, and that's more than enough. I prefer building my own communication protocol instead of using some other like OSC. -- Marc

OSC allows just about for any kind of protocol, it only suggests address + params syntax which to me seems a lot more readable than the proprietary protocol (i.e. "/midi status data1 data2").

I think you are missing the point of OSC. It is meant to be as flexible as one desires, offers time stamps, bundled messages and great efficiency over LAN. Anything streamed over internet can _never_ be considered real-time since there are too many unknown variables in respect to network performance, network latency, individual CPU load, router's traffic, etc.

OSC so far looks like one of the most promising protocols since it did not only receive commercial acceptance (albeit small one), but also relatively strong backing from many open-source apps, as well as the world of academia from where a number of good open-source apps stem from, including Pd.

The problem with open source community is that everyone thinks that they have the best idea as to how to implement a particular thing, so we always end-up having 100 crummy solutions to the same problem with non-existent documentation, and 0 usable ones. OSC on the other hand is greatly annotated, exists in a form of a library, and is as abstract as one needs it to be (sends strings, floats, and ints -- what else do you need?).

It would be nice if everyone embraced the same technology (rather than reinventing the wheel), so that in the long run we can interconnect as many apps as possible. Otherwise we'll always have to regard the concept of an audio workstation utilizing open-source solutions a geek/hacker toy.

Ico