SerialOSC as a hub for Monome-compatible OSC devices

[ambv]

The idea comes from the Norns Study Group Discord.

Since Arc is now discontinued, many people turned to TouchOSC to use it as an Arc-like controller. The experience is quite different from a physical Arc but it's better than nothing. We'd love it if it were more seamless, and this requires serialosc integration.

serialosc is an OSC "name server"

Now, on the PC many existing integrations (like pymonome) assume that they can discover Arcs and Grids by asking localhost:12002. It's a seamless experience because when you connect a physical Grid or Arc, the serialosc server creates a new process listening on a new port for each device, and notifies the subscribers.

Of course, at the moment, serialosc is unaware of TouchOSC already exposing an OSC port somewhere on the network, so existing software subscribing to serialosc won't know about those.

The problem

While you can go and adjust each such subsystem manually to look for a specific OSC host:port pair for an "Touch OSC Arc" out there, it's brittle and in some cases awkward to modify. In pymonome's case it would require copying and pasting the code essentially to circumvent going through serialosc.

The idea

If serialosc allowed registering an arbitrary device, like this:

/serialosc/register sssi <id> <type> <host> <port>

then we could make TouchOSC ping serialosc first with this information, and then all software which already supports Monome Arc via serialosc would just work.

Open issues

Of course, externally registered OSC targets can go away at any time so we would have to handle this somehow. The easiest would be to provide the /serialosc/register with a TTL, i.e. if another message of the same sort doesn't come within 60 seconds then remove the registration from the roster and notify subscribers that it went away.

Alternatively, serialosc could itself ping the registered host:port combinations to check if they are still alive. That's more work though.

What do y'all think?

cc @okyeron @Dewb

[tehn]

one alternative to querying port 12002 is to just rely on zeroconf, as each connected device announces itself: https://github.com/monome/serialosc/blob/main/src/serialosc-device/zeroconf/common.c#L47

early on when serialosc was initially written zeroconf support wasn't 100% robust on all operating systems without fiddling, hence the port 12002 provides similar functionality.

of course, this would require the device selector code to use zeroconf instead of the port 12002 negotiation--- which currently most do not do. for example, the max/msp "serialosc.maxpat" abstraction (which is an abomination of complexity for such a simple task) uses js and a bunch of async messages to serialosc to populate the device dropdown.

so, there's not a perfect no-code solution here, but what i'm suggesting is that if we collectively move towards using zeroconf instead of port 12002 that would mean any application/bridge could publish its own zeroconf and function as a virtual monome device.

(that's the dream at least, if operating systems/etc cooperate)

[Dewb]

This is excellent news! I didn't realize serialosc still published hardware devices via zeroconf.

My interest in this conversation was about making the grid-client infrastructure in VCV Rack something that can be documented/shared for other Rack module authors as a library/sample. Right now I could put together a serialosc hardware-only example, but the virtual grids have parallel, in-process infrastructure that can currently only be used by the monome-rack plugin. (Parallel infrastructure that I would be more than happy to get rid of.) If I switch discovery to zeroconf and start advertising the virtual grids via zeroconf, other plugins could "easily" add both hardware & virtual grid support.

[ambv]

@tehn Thanks for your quick response, Brian. Would it make sense for Norns to discover those zeroconf devices? That way I could use my actual Arc connected to the computer with a Norns on the same network, which would be pretty sick 🤩

[tehn]

it's of course possible, but it's also a somewhat heavy lift to add a bunch of zeroconf negotiation to the existing norns device tree as a core feature.

could be done with a mod as a "hack"