[question] Osc support for Go

[avlapp]

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]

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]

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]

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]

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]

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.
#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]

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]

This was recently added, which surprises me a bit if it's used for years in many projects.
#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]

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]

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/