Request: JUCE 4 OSC module implementation


#1

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.

Cheers,

Fred 

 


#2

Hi Fred,

I've been asking about a similar thing here:

http://www.juce.com/forum/topic/osc-functionality-review

I have this particular use case where there are multiple devices writing to a single workstation (and back of course). Though to be honest, what I had in mind for service discovery was an OSC hack; A broadcast UDP message with a few params about service types and device uuid.. ZeroConf is nice, but it's heavy, too.


#3

Hi Fred,

You're right, it would be interesting to separate the transport from the message logic more clearly, and to give the user access to the binary format direectly. I'll put it in our backlog... Is that a general suggestion, or do you have a specific use case that requires this stuff?

About the socket handling questions: I'd like to pass that on to Fabian, he's the network/socket expert ;-)


#4

I agree that it would be good if the user could send the OSC data manually (maybe by even sending it over a completely different transport like firewire or something - after all the OSC spec says nothing about transport). For this, the OSC classes would require a method to access the raw data. 

The datagram socket (which is used internally by the OSC module) does have a read method which will also return the sender's ip address.

Although we have no specific support for zeroconf, we do allow opening the datagram socket's as a broadcast socket. You can also open it on a multicast address if you want. With a bit of work you could either create your own discovery mechanism or implement a standardized one.


#5

Hi Timur,

Thanks for getting back on this request. I do have a specific need (sending OSC over BLE) that I address for now with another C++ OSC library. So I would need this access to binary data before switching over to this new JUCE module.

Cheers,

Fred

 


#6

Hi Fabian,

Thanks. About getting the sender's IP address, I do think it's usefull in many cases of bidirectional OSC communications over UDP. There's no other clean way to ask a question to a device such as "what's you firmware number", is there?

About ZeroConf, I don't have experience with alternatives or making your own. But networking audio becoming more and more common, it would make sense to me to package some form of solution in Juce. Who wants to work with fixed IPs nowadays?

Cheers,

Fred


#7

Hi, indeed, thanks for pointing this out! smiley


#8

Interesting use case! I'll have a think about whether the API can be opened a bit more to allow you access to the binary format. It's in my backlog  now ;-)

 


#9

Hi,

Just bumping up my request about splitting OSC and its UDP transport / or making it possible to insert a listener for UDP sender information.


#10

Hi,

As I already said, it is in our backlog, so no need to bump! We have to prioritise such requests against other features we are developing, and we're also a bit short on developers right now (see our job opening here), so please be patient. It will happen eventually. It's a really nice request and I'd love to refactor the OSC API accordingly whenever I get the time to do it.

If it's a really urgent and critical feature for you or your company, please send me a PM.