Debugging the serialosc launched by max?

[amj]

Hey folks! First time posting. Hi! I’m a programmer by trade, and have gotten into grid things for my son, who loves the blinky-button videos.

Would love some assistance debugging connecting a trellis-based arduinome to max. Some preamble:

• It’s a bunch of adafruit trellis’ connected to an arduino mega 1280.
• Grid works and is physically fine – standard arduino sketch showed each button working & addressable as expected
• the mac FTDI stuff is all good, i’m on el-cap, i’ve got the official FTDI kexts, etc.
• AFAICT from inspecting the serial output, i’m speaking valid modern osc, not 40h.

So i’ve got a (physically functioning) device that’s talking osc, where i’m having trouble is tracking down what’s happening w/ serialosc and the max bridge.

• I’ve used piraterename to update the FTDI serial to something monome-like (manufacturer ‘monome’
• I can see the grid in max using the ‘monomecereal2.0’ patch found here: https://github.com/rbnstubbs/trellis-monome/tree/master/clients . In particular, i can see the udp messages show up on localhost:8000 once i’ve turned on serialosc via the button in the monomecereal patch
• but the grid isn’t detected by any of the monome_sum apps, or other monome apps.

So my questions are:

• how can i introspect the serialosc bridge launched (i see it via ps auxw | grep serial) from within max?
• how is it different from the monomecereal2.0 patch?
• how can i manually run the serialosc-device binary against my /dev/tty.USBserialblahblahblah/? --help gives me nothing, --verbose gives me nothing, they all just exit immediately w/ error code 255.

So far, max is kinda driving me crazy because i can’t see any of the log messages when things go wrong

Apologize in advance if this is all well written up somewhere, i’ve been digging through years of old docs & forum posts trying to find things that are a) current and b) applicable.

Thanks in advance for any help y’all can provide! Here’s hoping i can show my son banging away on some buttons making noise soon

[amj]

might as well update with my experiences to help the next person:

I happened upon another impl of the serialosc protocol here: https://github.com/TheKitty/Untz_Monome , and it’s fantastic – very clear, readable implementation of the protocol with a helpful DEBUG compilation mode to reassure me that no, i’m not crazy, everything’s hooked up correctly.

My hypothesis is that the other firmware was not a complete implementation of the serialosc protocol and so it probably was failing some part of the handshake where it identifies itself; TheKitty’s implementation is clean, readable, and (looks) complete, so my guess is that was the problem.

So after reflashing with that build, i was able to get Max to recognize the grid! The grid-test sketch looked great, although it seems to think the grid is a 256 instead of 8x16 – not sure if that’s normal for grid-test or what, because it’s again a totally opaque thing.

Anyway, the new problem is that the monome apps don’t seem to work; i’ll try to get some video, but step is totally glitchy, all sorts of lights on that shouldn’t be and other things that look wrong. My guess is the serial speed is wrong (115200? or something else? who knows!), or the grid is somehow advertising itself as a 256 instead of a 128 and happily fiddling memory out of its range.

So i’m back at wanting to try to debug the messages happening on serialosc (some nullmodem emulation?) and digging through the decade of docs. I’ll try and post video of what’s happening, i know the above explanation is kinda crap.

If anyone out there has any ideas, thanks in advance!

[tehn]

it shouldn’t matter if it’s recognized as a wrong size. you’re saying grid-test worked?

if the serial speed is wrong, everything would be broken.

to clarify the thread topic, the max “serialosc” is just an OSC client, not serialosc itself, which is a command line utility. i don’t believe serialosc itself has debug modes you’re looking for, but here’s the repo: https://github.com/monome/serialosc

[amj]

Wow, the man himself! Thanks much for the reply

Further investigations: Looks like the firmware linked above doesn’t actually correctly implement serialosc; opened issue. If there isn’t a test suite for serialosc already i should probably write one

I’ll try compiling some debugging/logging statements into serialosc and see what i find – thanks!

[amj]

Update: after fixing up the arduinome’s firmware to more adequately comply w/ the mext protocol as i understand it, i get much better results. Pull request. Now, it seems like the problem is latency; i haven’t looked under the hood at the trellis libraries yet, but my hunch is there’s plenty of optimizations left. Also, it looks like there might still be some timers to turn off & other things to make more efficient.

I also am using an arduino 1280 from 2009, who knows, maybe they got faster since then