Hi Juce Guys,
I've attended the great JUCE conference a few days ago and was quite interested by the new OSC module. A lot of what I've seen is clean and clear, however I wanted to share some suggestions for improvements based on some of the typical needs:
First, since OSC is not tied to a particular transport protocol/layer, I don't think your classes should hide some UDP network goodness behind the scene. Ethernet+UDP is a natural companion, but it should be clear that's what is being used. The OscPkt library, although not flawless, makes this clear distinction. Alternatively, giving access to the binary package so that it can be sent by other ways. One nice usage is sending OSC over Bluetooth Low Energy! Pretty cool I find.
Secondly, a common pain I've encoutered with OSC+UDP is replying to a message: The IP address of the sender is not usually easy accessible from an OSC handler function.
Linked to dealing with IP addresses, a service discovery module would be a logical addition. Did I say ZeroConf?
Finally, again about OSC+UDP: a message handler might receive messages from multiple senders. And might need to forward the message to various other applications/devices, or might need to reply to the sender. All of it requires a handling of sockets which allows defining destination IP address and port on-the-fly, without opening/closing sockets constantly.
I hope it all makes sense, otherwise I'll be happy to go into more details with you.