search

hypebeast / go-osc

Open Sound Control (OSC) library for Golang. Implemented in pure Go.
MIT License
200 stars 46 forks source link

[question] Osc support for Go #59

Open avlapp opened 2 years ago

avlapp commented 2 years ago

Is Go a good language when one wants to use OSC?

How good is this OSC library for Go? How does this library compare to those in Python for instance (python-liblo)?

Go seems to be interesting language and faster then Python, but I need a good OSC library.

loffa commented 2 years ago

I have been following this repo for a long time and it seems to be slowly dying. Looking at both merges and code issue progress in the last year shows very little time has been spent on it by the owner. Since I needed a good lib for communication with a Behringer X32 sound mixer I created my own library gosc (look at my profile) replacing this mostly dead lib.

Then i used my lib successfully in creating a OSC<-->MQTT bridge.

I do most of my development in Golang and agree that it is a good and versatile language fit for most server side applications. However I have not tested the libraries in python that you mentioned.

avlapp commented 2 years ago

Liblo is for c/c++ and has there been for a long time: http://liblo.sourceforge.net/ pyliblo is a wrapper for python: http://dsacre.github.io/pyliblo/doc/ This does osc in realtime iirc: https://github.com/fundamental/rtosc

c/c++ might be the safest choice for osc, but Go seems to be a ideal language for me / a hobby / community project.

glynternet commented 2 years ago

I think "slowly dying" is a little bit of a harsh description. This package is basically feature complete and has been used in many production applications for years without issue. Personally, I've used it extensively in my own applications without issues related to correctness and/or performance.

Either this or the loffa/goosc would be fine for your applications if you choose to go with a go implementation. Choose whichever codebase brings you the most confidence or joy.

glynternet commented 2 years ago

The testing on loffa/goosc at the moment leaves something to be desired, I personally wouldn't use it in production its current state but would not judge anyone else for doing so.

avlapp commented 2 years ago

This package is basically feature complete and has been used in many production applications for years without issue.

This was recently added, which surprises me a bit if it's used for years in many projects. https://github.com/hypebeast/go-osc/issues/50

Either this or the loffa/goosc would be fine for your applications if you choose to go with a go implementation. Choose whichever codebase brings you the most confidence or joy.

Could you be specific?

loffa commented 2 years ago

This was recently added, which surprises me a bit if it's used for years in many projects. #50

It have not been added yet either. This is the main reason for me starting my own lib. I needed to write and read sequentially on the socket. The issue is still open and the code for it was submitted May this year (#51) and has not been reviewed yet.

Could you be specific?

The gosc package is in early development and no official releases has been done. I have only done a few commits and the tests don't cover all of the functionality of the lib (contributions welcome of course). Tests need to be extended and cover much more of the package before a first release, probably running automatically with GitHub Actions.

glynternet commented 2 years ago

This was recently added, which surprises me a bit if it's used for years in many projects. https://github.com/hypebeast/go-osc/issues/50

My understanding is that OSC is traditionally a UDP based protocol, so servers should not need to respond. I believe most applications will be based around UDP as a fire-and-forget protocol.

avlapp commented 2 years ago

For reference, there is also: https://github.com/scgolang/osc

Which also support Unix Sockets (and reply to sender?), but no TCP I think.

avlapp commented 2 years ago

I found this about bidirectional messaging:

"4.6 Network Topology and Routing

The OSC 1.0 Specification included some lan- guage regarding OSC client and server end- points. In fact this distinction is not necessary and OSC may be used on unidirectional trans- ports, and more complex network topologies in- cluding multicast, broadcast and peer-to-peer. The OSCgroups project provides a method for achieving multicast routing and automatic NAT traversal on the internet [Bencina, 2009]. A shortcoming of many current OSC imple- mentations using UDP/IP is missing support for bidirectional messaging. As a best practice implementations should try to leverage as much information as the transport layer can provide, as this makes more simple the task of configu- ration of the endpoint addresses in applications as well as stateful inspection at lower layers." https://opensoundcontrol.stanford.edu/files/osc-best-practices-final.pdf

See also, chapter 2.1 of this useful doc, which talks about "an ACK packet" design for UDP. https://beej.us/guide/bgnet/html/