In the liblo c/c++ osc library, one can specify a method which matches a osc message based on address and types:

/* add method that will match the path /foo/bar, with two numbers, coerced

• to float and int */
  lo_server_thread_add_method(st, "/foo/bar", "fi", foo_handler, NULL);

So "/error", "sis" matches a other message then "/error", "f"

As far as I can see this is not possible in scgolang/ocs

Liblo:

https://github.com/radarsat1/liblo/blob/master/examples/example_server.c
https://github.com/radarsat1/liblo/blob/master/lo/lo_types.h

Handle errors as discussed here:
https://go.dev/blog/go1.13-errors

Problem

OSC is an encoding, not a protocol.
See Adrian Freed's comments here: https://forum.pjrc.com/threads/18849-Open-Sound-Control
It would be nice to be able to use this package with networking protocols as well as serial.

I'm opening this issue as a way to jot down my ideas about how to do this.

Solutions

1. Encoder/Decoder

We let users provide their preferred io.Reader or io.Writer implementations and encode OSC packets using those.

Advantages

Simplicity

The code in this package could be very clean and concise, truly transport agnostic.

Disadvantages

Sender information

Anytime I write a method that replies to the sender I use the Sender field of the Message type, which is a net.Addr that we get by using ReadFromUDP.

If we go this route then this would have to change (possibly requiring updates to a lot of code).

One idea is to change Sender to an io.Writer. If this feels right in practice then this might make it worth updating everything out there right now that depends on Sender being a net.Addr.

Usability

It might make some people feel that the package is to hard to use if they have to initialize their own io.Reader or io.Writer. Maybe this shouldn't be a big concern because most Go programmers are probably familiar enough with the standard library to not care too much.

2. Conn types

We already have UDPConn.

We could just add TCPConn to round out network protocol support.

And maybe USBConn for serial connections.

Advantages

Package consumers don't need to write as much code.

Disadvantages

We have to maintain more code. We'd probably end up implementing the Encoder/Decoder solution internally anyways.

Hi!

My linter found this:

And I think it should not be there:)

Please check it out!

feature request: tcp support.

(interesting library, thanks for your work. Are you still maintaining it? @briansorahan )

This code does not handle nested bundles.

Relevant content from the OSC 1.0 spec:

When bundles contain other bundles, the OSC Time Tag of the enclosed bundle must be greater than or equal to the OSC Time Tag of the enclosing bundle. The atomicity requirement for OSC Messages in the same OSC Bundle does not apply to OSC Bundles within an OSC Bundle.

Sending a empty string doesn't seems to work using osc.String("")

Error 9912

https://github.com/radarsat1/liblo/blob/cb6f43da7cc137a2a64f129cdbb54638658a0d30/lo/lo_errors.h#L35
#define LO_EINVALIDARG 9912

Serve returns, which makes it impossible to start 'dispatching' if a server stops and is restarted?

https://github.com/scgolang/osc/blob/v0.11.1/udp.go#L110

I know this library is probably not used anymore, I just want to make sure no one gets bitten by it. The timetag to time.Time conversion is invalid. See hypebeast/go-osc#56 where I reported the same bug in another (/ the other?) Go OSC library. The code is here.

The spec describes the lower 32 bits of the timetag as fractions of a second. That means each increment is 1e9/(2^32) s = ~0.233 ns. Currently, each increment equals one nanosecond.

If this lib is still used, I will happily provide a patch.

I have noticed that an application that i am developing which uses package osc has > 100% CPU load even when no OSC messages come in, when i build my executable with go1.9 and go1.10 on OS X 10.10 and 10.12. When i build with go1.7 and 1.8 the CPU load is just a few %, as expected. My application uses GLFW and OpenGL, it is fairly small and simple still, but it depends on some external hardware. I could try and make a more minimal application that doesn't have these dependencies and send you the source.

func (msg Message) Bytes() []byte)
https://pkg.go.dev/github.com/scgolang/osc#Message.Bytes

As example.

I see other packages using a pointer there:
func (msg *Message) Bytes() []byte)

Incoming OSC message with string argument $112 seems to be displayed as 12.
Needs further investigation

metakeule@61625ed
master...metakeule:osc:master

@metakeule

Related to #17

Liblo was detecting a error when a message argument was send as []byte{}, while scgolang/osc won't.

Looking at the liblo library, scgolang/osc might miss some validation functions when de-serializing a osc message

https://github.com/radarsat1/liblo/blob/02989c6c69f54157b8d9651fb8d9ad6de8128d59/lo/lo_errors.h#L35
https://github.com/radarsat1/liblo/blob/02989c6c69f54157b8d9651fb8d9ad6de8128d59/src/message.c#L964

Using a context in a struct seems to be bad practice in general.
https://go.dev/blog/context-and-structs

edit: probably already dealt with, using func names like DialUDPContext

"Argument represents an OSC argument. An OSC argument can have many different types, which is why we choose to represent them with an interface. "

Can't this be done in a more simple way with:

Arguments []any

This is what gosc is using:
https://github.com/loffa/gosc/blob/897721d54234/types.go#L27

edited: Ok, I see how to work with the different types now.

Is there support for OSC address pattern wildcards like '*', '?', '{,}' and '[]'?

func (conn *UDPConn) Serve(numWorkers int, dispatcher Dispatcher) error

When I set 8 workers instead of just 1, it seems I'm loosing message now and then. A list is returned and sometimes it doesn't have the right length. It didn't occur yet, when I've just 1 worker running. Will keep an eye on it, while using 1 worker.

edit: looks like a channel doesn't get drained properly, cause when it goes wrong, the list is one to short or one to long.

Note I'm new to Unix sockets in general.

This library seems to support OSC via Unix sockets. Sending and receiving seems to work fine, but how should the client get a reply from server? It should just read from the same socket isn't it? Does this library support this? @briansorahan