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
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).
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!
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.
It appears this dusty thread might be the best place for this question, but it just as much relates to the spec as the docs and I couldn’t find a thread on the spec.
pattern /prefix/led/level/map x y d[32]
...
d[32] = 64 states, 4 bit values, in 32 consecutive bytes
pattern /prefix/led/level/row x y d[8]
...
d[8] = intensities
...
if d[8] has more than 8 elements (multiple of 8) send multiple serial packets with proper offset
To me this looks like a d[8] should be an array of 8 bytes but this is not the case on my grid.
The d[32] works as intended. I pack the 64, 4 bit levels more or less like so…
for(int i = 0; i < 64; i++)
{
d32[i/2] |= level[i] & 0xF << 4 * (( i + 1) % 2);
}
when I try to send an array of uint8_t over serial in the format
[0x1B, x, y, d[8]]
I get alternating blanks on 0, 2, 4 and 6.
So I tried…
for(int i = 0; i < 8; i++)
{
d8[i/2] |= level[i] & 0xF << 4 * (( i + 1) % 2);
}
…and that works, meaning this is a d[4] with 4 byte level data.
