OSC to norns over USB?

I’d like to send OSC messages to norns over a wired connection. This would be from a microcontroller, so probably just sending raw serial messages. (or do I need to figure out bundling the message as UDP over SLIP or soemthing?)

How is norns listening for incoming OSC messages? Is this via libmonome?

If so - Is libmonome automatically listening to ALL incoming serial for OSC messages or would I need some kind of “connector” to establish a device connection (like with grid, etc)?
(or am I barking up the wrong tree here?)

Libmonome is for communicating with grid and arc via their serial protocols and does not use OSC at all – norns uses libmonome directly rather than using serialosc to mediate grid/arc communication. Matron hosts an OSC server listening on UDP port 10111 (code is here) which is what interacts with the Lua OSC layer.

If you want to interact with this OSC server so you can use Lua callbacks etc. I would guess you probably need to adapt your USB serial traffic to UDP somehow so you can talk to this server. Depending on the format you want the microcontroller to send you may be able to pull it off with a program like socat (this might be easier if your embedded target also runs Linux / otherwise has its own UDP-capable network stack) or some custom program mediating (I would probably go for this option for talking to a microcontroller over an ad-hoc protocol).

for the moment just looking for receive OSC.

from your message it appears I want to have the messages formatted as UDP. (and using some SLIPserial stuff)

The CNMAT OSC library offers a bunch of possibilities so I’m trying to narrow down what specifically I need to send.

FWIW - this is kinda stupid easy over WIFI with an ESP8266 or ESP32 (lots of examples of this)… but not very many samples of doing over a USB connection.

Oh yeah, if your Arduino is already sending OSC encapsulated in a SLIPSerial transport over the serial port then I would bet that something like slattach + socat is totally up to the task of passing that on as regular UDP traffic to localhost:10111, but I don’t know exactly the right way to invoke these tools for this application. Something like this stackoverflow may shed some light?

2 Likes

(slowly starting to wrap my head around this)

If the messages are sent with SLIPSerial then am I correct that they need to be “decoded” on the Pi end and that’s what you’re suggesting with slattach + socat?

:thinking: I may bail entirely on USB and do it over Wifi or even Ethernet. LOL.

EDIT: found this python SLIP->OSC example

Also a python serial-to-osc-converter

Also also (for later reference): A CNMAT article on OSC OVER THE USB-SERIAL TRANSPORT

This is cool but I think it’s a lot more complex than what you need – this is standing up a whole OSC server you could then connect other stuff to. If I understand right then the SLIP wrapper is basically just doing framing – that is, it is marking where one OSC packet ends and the next begins, since a raw serial port just works with bytes and doesn’t have any notion of a packet. So what you need is basically a program that breaks up the byte stream from the serial port into packets by finding the SLIP framing bytes (that’s what this code does) and then puts on the right header to create a UDP packet with the right destination IP + port, wrapping the OSC content unchanged. Once you’ve decoded the SLIP encoding into packets you could also do this part pretty easily with Python’s built in socket library.

Oh this is cool but also seems to be solving a different problem, where the serial traffic is not already OSC, but the serial data is in some fixed format and you want some code to generate OSC from that known format.

This article makes a good point that any kind of serial <-> UDP translation program is going to introduce latency and jitter, though it’s probably less than the latency and jitter inherent to WiFi.

1 Like

This is actually OK in my case since I don’t necessarily need to send OSC, I just want to get the controller data over to norns in some way I can work with it from a lua script. But it does require another “layer” or thing running on the receiving end which is less than ideal.

And yeah - I could probably just use MIDI, but that’s not the point of this particular exercise. :wink: