that’s not normal at all for any kind of UDP traffic, so i’d check your network / use the norns hotspot / use usb-thernet adapter as suggested. if the networking part is known to be good (e.g. you get reasonable latencies pinging the norns from the same device that’s sending OSC) then we indeed might have some traffic congestion issue (@jah didn’t you see something like this sporadically?)
if it seems like a specific issue with norns handling OSC, then we would need quite a bit more information to triage it - whats the network setup, what kind of data are you sending (and how much), what script/engines are running, CPU load if you can manage it, &c - with some more specifics (steps to reproduce) we can open an issue and check it out.
a general thing to keep in mind is that on norns, all communication between Lua and SuperCollider is accomplished with OSC messages over a local UDP port. so that traffic is competing for bandwidth with your networked OSC controller traffic. so if you have a script sending out tons of really fast control/note sequences, or something, you can expect other soft-realtime network traffic to be potentially slow (if it’s using TCP) or spotty (UDP.) (IOW: is there a correlation between lag/weirdness with your networked controller, and lag/weirdness with built-in controls / sequencing on the norns?)
there’s not really a standard way to do that.
i wish i could sticky this fact somehow: OSC is a transport-independent data format, not a communication protocol.
usually when we say “send OSC” it’s shorthand for “send OSC-formatted messages over a UDP or TCP network sockets.” if you want to use the OSC format on other transport layers, you need to make more decisions about framing and transmission rate and stuff. so there are different protocols that do that:
-
TouchOSC can connect to iOS devices to a host over a USB cable, if the host is running a special bridging app. the app uses a library called libimobiledevice - i don’t know a lot about this (docs arn’t so good) but i’d guess it gives support for apple’s MultiPeer protocol for mac, and whatever equivalent for windows. not clear to me if/how the library supports linux.
-
monome’s own serialosc sets up a little local networking service and dispatches serial data to/from monome controllers. (similar function as the TouchOSC bridge app, but kinda “in reverse” - host sees monome device as network endpoint, instead of iOS device as serial endpoint.) on norns we don’t use this - we opted to talk to monome controllers directly over the serial port, bypassing the networking layer. (instead of competing with lua-SC traffic as described above.)
-
CNMAT has an arduino library for sending OSC messages over the serial port. it is built on the SerialIP library and uses the SLIP encoding, which is a kindof standard way to emulate network protocols over a serial port.
we could add explicit support in norns for any of these methods. any of them would require work (of course), and all of them require different stuff to be running on whatever device the norns would be talking to.
so the solution would involve the question: what kind of device are you using to send the OSC data? and how would you connect it to a normal computer, instead of norns?
my guess is that the controller is an iOS device running TouchOSC, and further that there’s no way to use the wired mode with a linux host. if i’m wrong, awesome - adding support on norns would range from “trivial” to “probably straightforward.”
(to be clear, i also think this would be a cool feature to have.)
supporting devices that use OSC over SLIPSerial (like Arduino devices running using the CNMAT lib) would be “definitely strtaightforward,” and would require adding support for SLIP framing on serial ports, most likely in the C application layer of norns. (i also think this would be cool to have, but i’m unwilling to designate it as a necessary feature because i have no idea how many devices in the wild actually use this protocol - guessing not very many - and there are more pressing issues in the device I/O layer, like supporting multiple MIDI ports.)
