G.all(0) makes grid 64 40h flicker on norns shield

I got myself a norns shield and after a week I realised I really wanted to use a grid with it. There are no varibright grids available anywhere but I found a used grid 64 40h. It looks as if the case was 3D printed but I assume it was proper. I have tried it out with some different norns scripts after altering the code slightly but I always run into the same problem. When the script calls g.all(0) for the grid all the light flickers and is not properly redrawn. If I comment out all(0) everything works except lights are obviously not turned off properly.

I tried looking through the norns recipes and I searched the forum but I can’t find an explanation of why I am seeing this behaviour. I also tried slowing down the redraws but oddly that does not make any difference, which I was a bit surprised of.

Hopefully I haven’t overlooked something obvious. Thanks for your help!

hey hey! blast from the past :rocket:

after a quick conference, this is likely a libmonome issue. i’ve also worked on troubleshooting this a bit with another user who has an arduinome – you’re correct that the g:all(0) function doesn’t seem to perform as expected on these specific devices. but you can set state for each LED individually (see loom for a working example).

just wanted to confirm so you knew you weren’t overlooking something + we’ll follow back up with additional info after some digging :slight_smile:

this could also be a firmware issue. can you post a photo of the device? does it work with macos/etc?

Awesome! Thanks. I was scratching my head pretty thoroughly on this one :slight_smile:

@tehn: of course! Thanks for the excellent support

indeed it looks like a 40h-something. if you could get a photo of the circuitry we can discern if it’s an original 40h kit or a newer mk.

also let us know if you can get it working as expected with max/msp (etc) on a normal computer— that’ll help debug substantially.

I can’t take it apart right now (kids are approaching home and I need to cook) but I can run the examples from Grid Studies: Max - docs. I don’t seem to have lights on in the last patch (maybe I just haven’t studied it enough) but the first couple of patches deliver a nice steady light.

I can provide some info because I printed the case for this Grid. It is a Monome 40h DIY kit. It works on Win10 Ableton (e.g., Max for Live). In order to run it with the Norns Shield, the Lua scripts need to be “updated”. Unfortunately, I can not remember exactly how. I think in some scripts adding a further grid:refresh() to the gridredraw() function helped (which is a bit weird). Give this a try using the Awake script.

1 Like

I added another g:refresh() right after the g:all(0) and that worked! I wonder if the firmware is getting the order of the clear and the individual draw commands mixed up?

1 Like

Unfortunately, I can not say more about it. It seems to be a communication issue between the two devices. The help with the grid:refresh() works for some scripts (e.g. Foulplay), unfortunately not for all.

I finally managed to take the grid apart. Here is the board:

I hope that helps :blush:

1 Like

under the hood, norns only uses a single grid command: /grid/led/level/map.

this command is only sent from the grid.refresh() lua function. it is sent once per dirty quad (8x8 led grid region) with x,y offsets set to the “local zero” for each quad.

all other lua grid API functions simply update the buffered LED state and set dirty flags for each quad.

so one thing that happens is that norns assumes all grids have 4 quads. that means after g.all(), there will always be 4 led/map commands sent on the next g.refresh(). i guess this is technically a bug, but it doesn’t have any ill effects for newer grids. my guess is that the older HW/FW doesn’t handle the extraneous quads gracefully (or simply can’t keep up with the bandwidth.)

so here is a ticket to teach the norns grid middleware to respect device size. i will also check the driver code next time i am looking in libmonome.

in the meantime, a good question would be: what happens if you send, from max, four consecutive messages like:

/monome/grid/led/level/map 0  0  [0 ... x64]
/monome/grid/led/level/map 0  64 [0 ... x64]
/monome/grid/led/level/map 64 0  [0 ... x64]
/monome/grid/led/level/map 64 64 [0 ... x64]

(apologies, i’m not sure of the real max syntax for the char lists in level/map.)

1 Like

Hope it’s OK to revive this old thread, but it seemed related to my issue.

I have a green-LED Monome 40h that I’ve been using since buying it back spring 2007! It works great with my Monome Eurorack modules, but with the Norns all of its buttons just flicker.

I have tried digging through the source code of various Lua scripts to see if has anything to do with the 40h being monobright instead of varibright, but had no luck.

The video example below shows the Awake script handling user input, but it never seems to light up the grid properly. My Norns is running release 210927.

It would be cool to know if there is any hope for ever using my 40h with Norns, or if it’s just a lost cause. Thanks!

is that a fates? i haven’t heard many reports about monobright compatibility— if it’s a general issue, we can address it within libmonome, which is a lower-level.

Indeed, it is a Fates. I totally understand if Fates is something that can’t be supported!

it’s similar, hopefully should be identical if libmonome is the same version.

for what it’s worth, “series” walnut monobrights work mighty fine (by my own experience + those of @McNUG and @andrew).

as for earlier 40h i don’t know…

1 Like

I just found out that installing Norns 2.6.1 / 220129 via the Fates project fixed my 40h grid blinking issue. It’s like a night and day difference. Thank you to all the individuals who support older grids like mine!

1 Like

that would be me and @Galapagoose who fixed libmonome in that update. i was unsure the fates release caught up, but which is why i asked

I’m necroing this thread because I just acquired (for pure fetishistic reasons :slight_smile: ) a 40h 8x8, monobright grid with green LEDs and, using the latest Norns firmware, I noticed an issue that I assume to be related to the one presented by OP, even if it actually looks the opposite.

When I originally tested my new/old grid with a few scripts (awake, mlr, etc) I noticed that I/O seemed to work as expected, but LEDs would just flickr for a split second, instead of lighting up and staying lit.
I assumed it was a software issue, so I bought the grid, brought it home and investigated; long story short:

  • g.all(0) and g.all(15) work when called alone
  • g.led(x, y, 0) and g.led(x, y, 15) work when called alone

But this commonly used pattern:

g.led(x, y, 15)

results in x,y flickering for a split second, followed by an unlit grid.
I’m not sure what is (did not check the grid library’s source code), but I suspect it might be a timing issue, so I tried doing things more explicitly and found out that it only takes this to solve the problem:

for y=1,8,1 do
   for x=1,8,1 do
g.led(2, 2, 15)

It’s such a niche case and such a little hack that I don’t think it makes sense to patch the grid library; if I’ll find other hacks that might be beneficial to the community, I’ll make a monobright_grid lua library, that would plug on top of existing functionality similarly to what midigrid does for alternative grids.