#532

I’ve been experimenting with an 8x8 one of these using the Adafruit kit with Feather M4 Express. It’s working using @okyeron’s compiled code, and with my own version after I figured out the TinyUSB library hacks. The grid-test runs perfectly on Fates, Loom looks good, etc. Thanks for making this possible!

However, running Awake on Fates, the grid LED update doesn’t seem to work quite perfectly: only the top line of LEDs ever lights. It seems as though the code that resets the LEDs all off with every refresh executes before the other LEDs get a chance to light up. (Edit: I don’t think that anymore; see REPL investigation below)

Is this just me? Something to do with the Feather code? Or Awake itself? I can get things to behave a bit better by hacking the Awake script but wondered where the issue really lies.

Edit: looks more and more like a bug somewhere. I’ve been playing with the REPL.

g=grid.connect()
g:all(0)
g:led(1,1,10)
g:refresh()

behaves as you would expect, lighting the first LED and switching all the others off. But for other rows e.g.

g=grid.connect()
g:all(0)
g:led(1,2,10)
g:refresh()

the LED does not come on. Inserting an additional g:refresh() after g:all(0) makes it work.

Any ideas where to look to figure this out?

#533

Pretty sure you need a refresh() after sending all(0)

If that’s not in awake then… ???

Have you updated all your scripts to most recent versions?

#534

Thanks. Interesting… so you think the refresh call must be made before any other grid updates?

The code in Awake is very similar to this code from norns study 4:

function grid_redraw()
  g:all(0)
  for i=1,16 do
    g:led(i,steps[i],4)
  end
  g:refresh()
end

So there is a call to refresh but not until after some further LED setting is done. On my neotrellis grid at least, the further setting only works for row 1. Very occasionally the other LEDs that are set will flash on briefly.

Inserting an additional call to refresh straight after the all(0) gives better behaviour but again the leds flicker every now and then.

If the issue is with the script rather than my grid then obviously I’ll be relieved!

#535

Well… off the top not my head I’m not really sure. Would need to dig into the code again to remind myself how it works.

If you modified the neotrellis grid code then it is possible something else is happening to cause issues.

What did you change in the code (if anything)?

Edit - it might be useful to doublecheck grid functionality with the grid on your computer and Max with the Monome Home test patch. I’ve not done extensive 8x8 testing and maybe there are bugs?

#536

Thanks again for your help.

I haven’t made any significant changes to the code – just the colours for now – and the behaviour was the same with the precompiled code from your repo.

The monome home patch in Max seems to work just fine; I lost a few minutes gazing at the varibright map test.

Is there some way to log what data is being sent from norns (fates) to the grid over serial?

#537

Not an easy way really. but maybe not the issue here.

Looking at the awake code I think you’re running into something where the script is hard-coded for a 16x8 grid.


function gridredraw()
  local grid_h = g.rows
  g:all(0)
  if edit_ch == 1 or grid_h == 16 then

So - because g.rows is 8 - this next part will never execute.

You’d probably need to dig through this thread for making 8x8 modifications: Norns Scripts for a 64 Grid

#538

I honestly don’t think it’s as simple as Awake needing an 8x8 remix.

The code in Awake does execute because of the or, but in any case – and more significantly – the exact same behaviour arises with the norns-study-4 code which is super simple (and which I did amend for 8 columns), and with the three or four lines I tried in the REPL which I guess are the minimal example to show the issue. Something funny is going on. All the code I’ve looked through seems ok but I’m a long way from seeing the full picture.

Anyway, never mind. If nobody else is seeing issues then it is likely not a problem for other configurations and my little 8x8 use case is very niche. Thanks for taking the time to respond!

#539

on norns/fates, g:led() sets the state of an internal buffer, and does not produce serial traffic.

g:refresh() sends out the buffered state for any 8x8 regions that need refreshing, using the led/map message from the grid serial protocol.

the typical grid size is 8x16, divided into 2 regions (aka quadrants or quads). in the awake script, the loop over column numbers [1, 16] ends up hitting both regions, so on refresh(), two /led/map commands are sent every time.

one thing to check is that the 8x8 device is correctly handling the second /led/map, for the missing quadrant (by ignoring it.) the max script you tested may have been using different commands from the protocol (besides /led/map, there are also commands to set one LED per packet, one column per packet, &c.)

you could try modifying the awake script so it only loops for i=1,8 ...

1 Like
#540

Thanks for that. I infer that norns uses /led/map for every led-setting interaction with the grid, rather than using some of the other commands. Is that right?

Playing around some more I have come up with a shorter sequence of commands that exposes the issue:

g:led(9,8,10)
g:led(1,1,10)
g:led(2,2,10)
g:refresh()

After this, only led 1,1 will light. led 2,2 stays off. The first line is the one that causes the trouble, and only position 9,8 has this effect – I tried everything up to 16,16 and isolated this particular position as the troublemaker.

So, there’s a bug somewhere but I am on its tail!

#541

that’s right. (this could conceivably change in the future.)

how bizarre! yeah i would look for an issue on the LED driver end. maybe consider modifying the firmware on your 8x8 grid to ignore any /led/map with x/y offset greater than 7.

#542

Gonna reset my NT grid to 8x8 right now and do some testing. If you wanna do some back in forth in DM, hit me up.

1 Like
#543

As a followup - yeah this was a bug in my neotrellis grid code. Out of range values for setting leds were not handled correctly, so I think I’ve got that fixed up now. :slight_smile:

1 Like
#544

I was totally wrong about (9,8) being the only problem spot. Not sure how I got so mixed up. Anything x>8 with y in range 1-8 caused problems. The tireless @okyeron found the issue and fixed it.

#545

Hiya,

I have exactly the same problem as you with a 8*8 grid on a Teensy.

Only the First row works randomly. I ran the grid test and the grid is fine.

I was looking into it with @okyeron some time ago, but have left the bug for now.

But yes, im having the same behaviour which makes the grid unusable with Norns/Fates most scripts :frowning:

#546

Mine is working exactly as it should after a two line fix. Are you set up to compile the code if I show you how to fix it? (Requires hacking the TinyUSB library in a slightly tricky way that I’m not sure I can explain.) If so then DM me and I’ll show you the fix; if not then better wait for @okyeron to check everything out and produce an amended firmware.

#547

Thanks for your reply @hollasynth !
Unfortunately i just uploaded the latest neotrellis monome code to my 8*8 and nothing is working.
The start up led doesn’t either.
Im having trouble uploading the sketch to the grid. I know the grid is working good because i am using some of the neotrellis examples and they work ok…
Im up for compiling for sure! I have the teensy version :slight_smile:
Cheers!

Edit:
I compiled fine after a computer reset, no errors on arduino log, but when i plu my grid now to the computer it doesnt do anything…neither the start up flash light.

Do i need to make some modifications to the code like when it says

#define NUM_ROWS 8 // DIM_Y number of rows of keys down
#define NUM_COLS 16 // DIM_X number of columns of keys across

Edited 2: If i change columns to 8 i do get an error compiling:

neotrellis_monome_teensy:62: error: too many initializers for ‘Adafruit_NeoTrellis [2]’
too many initializers for ‘Adafruit_NeoTrellis [2]’

Edited 3: oh dear, i just saw the 88 settings in the ino file… i commented it out the 168 and made the 8*8 active, compiles well but no response from the grid :frowning:

Thanks

#548

Probably wrong addresses.

If you can find our previous messages When we were debugging that would probably help.

1 Like
#549

My adresses (tested) with the multitrellis are:

{ Adafruit_NeoTrellis(0x2E), Adafruit_NeoTrellis(0x2F) },

{ Adafruit_NeoTrellis(0x37), Adafruit_NeoTrellis(0x3F) }

Looking at the grid from the front:

Top left:0x2E Top Right:0x2F

Bottom left:0x37 Bottom Right:0x3F

Thanks!

Big shout to @okyeron and @hollasynth for helping me sorting it!

1 Like
#550

Tried out this new (to me) acrylic material for the neotrellis grid today:

(it’s a faux brushed aluminum surface)

It only comes in a 1/16inch thickness, so needed to do the layer stack a little different, but works out pretty close to what I had with the EVA layer.

5 Likes
#551

That’s one sexy look right there! Nice.

1 Like