#1

I’ve been using serialosc 1.4 on my mac and it’s working fine, so no issues here, but it seems like the latest documentation on monome.org/docs is a bit light. I remember a few years ago there was a serialosc devtools max patch which clearly documented how to communicate with serialosc, as well as receive debug messages from it.

does anyone still have the serialosc devtools max patch? does it even apply to the latest version of serialosc? I know it used the old serialosc max patch, and i know sending messages to/from a grid are the same, other than varibright led messages of course.

i’m not bad in max these days, and I can make out what’s happening in js, but when I open the latest serialosc max patch i’m befuddled and flabbergasted. what are my options with it? what messages can I send to the bpatcher with regards to monitoring i/o? what does everyone consider “best practices” these days? are we assigning our own prefixes to a given patch/app or is it all based on how we define sends and receives with [prefix]to-sosc?

i’m looking for more extensive documentation on interacting with serialosc in max than what is currently available, and curious about best practices :slight_smile:

#2

I don’t think the new version takes any messages at all (aside from the actual OSC and ‘bang’). And the old devtools version applies only to the old version. It’s a shame as that one was much more documented (including the devtools), and you could change fonts/colors/etc…

Best practice wise, it’s more standard just having a generic /monome prefix. I know (think actually) that the most recent monome apps/devices write the LED state to a buffer and then update the actual devices every 20-30ms instead of sending out a stream of OSC messages, but that’s more of a programmatic concern.

I just pour out the OSC messages as fast as they come and don’t really run into problems (other than some animations not showing up well on the arc due to speed issues).

1 Like
#3

Here’s the dev-tools maxpatch.
serialosc-devtools-1.maxpat (178.6 KB)

1 Like
#4

awesome, thanks rodrigo! Really appreciate the response too. I’m going to have to look into the buffer concept—20-30ms seems like a long time in the audio world to me!

#5

Happy to help.

That does seem like a long time to me, but I would imagine all the devices have something similar happening internally either way.

#6

That’s over 30 frames per second, you probably wouldn’t notice the difference if the LEDs updated any faster.

#7

That… is a very good point. And very obvious now that you mention it. Sometimes I get a little too myopic :slight_smile:

#8

Throttling messages (ie sending every 20-30ms) may be considered due to some monome devices actually crashing if you send too much data too fast. I’ve run into this using my arc (which are super sensitive) together with a grid.

See Rate-limiting led messages

If you’re only using a grid you probably don’t need to worry about it.

#9

Great! Thank you, Rodrigo. I’m trying to debug flaky behavior on win10, and the devtools are a lot of help.