pattern: /prefix/led/level/map x y d
desc: set 8x8 block of leds levels, with offset
args: x = x offset, will be floored to multiple of 8 by firmware
y = y offset, will be floored to multiple of 8 by firmware
d = intensities
serial: [0x1A, x, y, d]
is d bitwise data (like with /grid/led/map ) or an array or ?
I am getting good results now sending /grid/led/level/map commands to my teensy grid from my Mac (using maxpats). However, when I plug into my raspi-norns, I’m not getting leds lighting up properly (they flash very intermittently).
Any script that lights/dims a specific led works fine for me (like jah/step.lua). But, any of the tehn scripts that do the following do not work.
So perhaps I’m still parsing the data wrong, or norns is sending things in a slightly different way than Max/serialosc on my mac?
@zebra can you confirm that norns is sending the level/map data in the same exact way? I can’t make sense of ‘dev_monome_refresh()’ in device_monome.c
Also from the norns docs - the following makes zero sense to a newb (like me). What’s a quad, why is it dirty?
update any dirty quads on this grid device]
EDIT: curious - if I change to the following I can get awake to show leds
i am pretty confident that the payloads from libmonome and from avr32 driver are identical, though haven’t explicitly verified this for a long time. guess i’d try going in and logging the payload data when pack_nybbles is called. in the link above.
What’s a quad, why is it dirty?
a quad is a block of 8x8 LEDs addressed by a single /grid/led/level/map command. the data for a quad is “dirty” when it has changed and needs to be sent to the device.
anyways, if it works but takes 2 refreshes then i’d guess at some kind of mismatch in the serial framing mode. or the rate. or some other reason that the teensy serial rx buffer read works with 2 bytes but doesn’t complete with 35 bytes.
in other words, looking for some difference on the wire, rather than in the payload data. b/c norns is using a linux tty device, and the aleph/euro/arduino version is just using a raw serial port peripheral, probably with waits between bytes.
or yeah i guess a bug in the way norns code uses the dirty flag? i think we would have caught that but i will try to verify.
Mostly just commenting so as to make the forum follow this thread.
But, hey. While we’re here…
(this is somewhat off topic)
/grid/led/level/row feels less responsive if /sys/rotation is in play. Wondering if that’s real or imagined. (I designed my app 90 degrees off from where it probably belongs)
I’m probably just forcing an extra translation step onto serialosc, which could be optimized away by restructuring my code to simply face the right direction. But I’m a little nervous that maybe rows are just faster than columns somehow?
Would the quads [2, 3] come through as another chunk of mext 0x1A data (with x, y offsets)?
sorry, right. well, that’s strange. what should happen is that if you change a single led, and send refresh, only a single 35B map message will go out, for whatever quad contains that led. and changing the loop indices should not make a difference.