ahh gotcha, thanks for clarifying.

cool well gridbuf is kindof a utility module for doing stuff like setting whole columns, doing bitwise ops, clamping values, swapping whole buffer states, &c. it’s old and incorporates some mistaken assumptions. (like the “TODO: use map when available” - led/map serial is always used under the hood already, other set serial commands are never used .) but some people find it useful as an additional layer of abstraction / safety on top of the driver.

and that’s my main point, which feels repetitive now so i’ll shut up after this: if you want midi-grids to work like monome grids, you gotta add an additional buffering layer per device, that is analogous to the one in matron/src/devices/device_monome. this is true whether you use gridbuf or not. without that there will be problems with scripts like awake that don’t use gridbuf and rely on the driver layer to do buffering.

BTW: everything in monome/dust is deprecated, since norns 2.0. any of thost scripts that are still maintained, have been migrated to individual repos. i guess it’s still up because there are still some “orphaned” scripts and we don’t want them to disappear completely.

Thanks Zebra, I had looked at device_monome a week or so back, but after reviewing it again I’ve picked a few more useful idea’s (like dirty quads)

Just to expand on my thinking for everyone, currently midigrids is actually 3 different implementations (MG, mg128 & mg256), when it should only be one with different invocations (I’ve yet to identify the best way to do this in lua).
And its high level architecture should be something like:

  1. Virtual Device (w/ buffer) Can be 8x8, 16x8, 16x16 or potentially any other size
  2. A device buffer (8x8 by default) + “special button” buffer
  3. Device renderers (this is where various sysex and buffering stuff can happen)

On the led/map todo, the render function is the primary one I’d be looking to replace in an extended version for midigrid. For example LP mini actually has a led/set like (I think?) midi sysex message, but its hard to use in the current setup as it sends two led colors per midi message.

This. Your whole post is a better, more accurate take on Issue #12 from the github repo which I opened. Please do jump in, as I don’t and won’t have time for this work for a while; OTOH, I’m looking forward to reviewing any PRs you might open :grin:

@zebra; tyvm for the tip on gridbuf, ‘cause that’s definitely where I had been planning to start when trying to better integrate midigrid into the norns ecosystem

fwiw, out of curiousity i checked about 50 scripts from the library, trying to focus on those using grids, and only 2 of them use gridbuf - glut and its progeny mangl. (makes sense cause same person wrote glut and gridbuf.)

which isn’t to say it’s not a quite useful library, just that you can’t assume everyone is using it.

2 Likes

I’m getting a traceback related to all_led_sysex, this is using a Launchpad 1 (product ID is NOVLPD01, I think that’s what it means) with Fates. The Launchpad shows up on System > Devices > MIDI, but when starting up a script (tried awake and earthsea) with the code

local grid = include('midigrid/lib/midigrid')

just before grid.connect() is called, I get the load fail message and the following

traceback
# script load: /home/we/dust/code/awake/awake.lua
# cleanup
# script clear
including /home/we/dust/code/awake/lib/halfsecond.lua
including /home/we/dust/code/midigrid/lib/midigrid.lua
including /home/we/dust/code/midigrid/config/launchpad_config.lua
`midigrid.device` is:
event function: 0xaf1fc8
id 1
name Launchpad
port 2
dev userdata: 0xa9e7a8
`midigrid.device` is:
event function: 0xaf1fc8
id 1
name Launchpad
port 2
dev userdata: 0xa9e7a8
midigrid "launchpad" has 8 rows, 8 cols
### SCRIPT ERROR: load fail
/home/we/dust/code/midigrid/lib/midigrid.lua:200: attempt to call a nil value (method 'all_led_sysex')
stack traceback:
/home/we/norns/lua/core/norns.lua:126: in method 'all_led_sysex'
/home/we/dust/code/midigrid/lib/midigrid.lua:200: in method 'all'
/home/we/dust/code/midigrid/lib/midigrid.lua:97: in field 'connect'
/home/we/dust/code/awake/awake.lua:45: in main chunk
[C]: in function 'dofile'
/home/we/norns/lua/core/script.lua:160: in function </home/we/norns/lua/core/script.lua:160>
[C]: in function 'xpcall'
/home/we/norns/lua/core/norns.lua:127: in field 'try'
/home/we/norns/lua/core/script.lua:160: in function 'core/script.load'
/home/we/norns/lua/core/menu/preview.lua:21: in function 'core/menu/preview.key'
/home/we/norns/lua/core/menu.lua:139: in function </home/we/norns/lua/core/menu.lua:116>
# script clear

Edit:
having now looked at the code, config:all_led_sysex() is called unconditionally, and that doesn’t exist in launchpad_config. I noticed there’s a related TODO in there, but I’m unsure I’m understanding this correctly as several people in this thread are reporting success with a Launchpad.

midigrid.lua

https://github.com/miker2049/midigrid/blob/5a430aca67d9d0864028bca781fd2bdb29bc3796/lib/midigrid.lua#L200

@pfig Yup, you are on the right track that all_led_sysex is not implemented for several devices.
I also think that all_led_systex is currently called 64 times … and it’s also not compatible with older LP devices. FYI, I’m not sure if anyone got the original LP working at any point, but if you have any experience with Git then the previous version of midigrid worked better for older LP devices.

I’m working on making the whole affair work a lot nicer and in a way that should avoid changes for various devices upsetting everything else. Can’t make any promises about when I’ll be finished as I have a lot of family commitments, but watch this thread for updates.

1 Like

I posted this a while ago, but don’t let it dissuade you from experimenting - I gave up on it pretty easily, as I was already looking for an excuse to upgrade :slight_smile:

My really OG og Launchpad will probably never work. I found research online indicating that the the oldest Launchpads can’t respond quickly enough to a low-latency/realtime Linux kernel before it (the kernel) times out.

1 Like

Sorry for the Noob question. Just got a dirt cheap used apc mini to see if I could get this to work on fates. The apc works, tried it with ableton, and it is recognized as a midi device on fates. Modified the script on awake and mir as instructed and both run but give me “Error: no device found.” I have loaded the apc on the various midi ports of fates and tried each and get the same error.

double check the name of your device in the norns midi device menu is the same as the ones in the device list

Device name in Norns menu is APC MINI and in the midigrid config file is is device_name=‘APC MINI’

Okay, found issue in midigrid/lib/midigrid at line 30 line read apcmini = ‘apcmini’, modified to apcmini = ‘apc mini’, and now it finds my device. Did the same on midigrid/lib/mg_128. Now, however, I am getting load fails similar to pfig above, but the errors are different for midigrid and for mg_128

midigrid

SCRIPT ERROR: load fail

/home/we/dust/code/midigrid/lib/midigrid.lua:200: attempt to call a nil value (method ‘all_led_sysex’)
stack traceback:
/home/we/norns/lua/core/norns.lua:126: in method ‘all_led_sysex’
/home/we/dust/code/midigrid/lib/midigrid.lua:200: in method ‘all’
/home/we/dust/code/midigrid/lib/midigrid.lua:97: in field ‘connect’
/home/we/dust/code/awake/awake.lua:45: in main chunk
[C]: in function ‘dofile’
/home/we/norns/lua/core/script.lua:159: in function </home/we/norns/lua/core/script.lua:159>
[C]: in function ‘xpcall’
/home/we/norns/lua/core/norns.lua:127: in field ‘try’
/home/we/norns/lua/core/script.lua:159: in function ‘core/script.load’
(…tail calls…)

mg_128

SCRIPT ERROR: load fail

/home/we/dust/code/midigrid/lib/mg_128.lua:279: attempt to index a nil value (global ‘caps’)
stack traceback:
/home/we/norns/lua/core/norns.lua:126: in metamethod ‘__index’
/home/we/dust/code/midigrid/lib/mg_128.lua:279: in method ‘refresh’
/home/we/dust/code/midigrid/lib/mg_128.lua:127: in field ‘connect’
/home/we/dust/code/awake/awake.lua:45: in main chunk
[C]: in function ‘dofile’
/home/we/norns/lua/core/script.lua:159: in function </home/we/norns/lua/core/script.lua:159>
[C]: in function ‘xpcall’
/home/we/norns/lua/core/norns.lua:127: in field ‘try’
/home/we/norns/lua/core/script.lua:159: in function ‘core/script.load’
(…tail calls…)

The midigrid error is the same pfig got above .“to call a nil value (method ‘all_led_sysex’)”

The mg_128 error is “attempt to index a nil value (global ‘caps’)”

Thanks for ideas and suggestions.

Does some device, other than the LP / LP mini use midi notes for “non-grid” or special function buttons?
The following code just makes the bottom two rows of the Launchpad mini to fail to register presses and proper cc messages are already rejected.

Trying hard not to break equipment I don’t have access too…

-- "musical" notes, i.e. the main 8x8 grid, are in this range, BUT these values are
-- device-dependent. Reject cc "notes" here.
elseif (note >= 0 and note <= 88)
and (midi_msg.type == 'note_on' or midi_msg.type == 'note_off') then

Change 88 to 120 and it should work

Sorry if the intent of my post is not clear, I’m trying to understand why this is filtered by note at all, as it’s filtered by midi_msg.type which I see as the correct way to filter out cc events.

Trying to get to a point where I can raise a PR that will fix the immediate problems people are facing with older devices.

I’m working from memory, but I believe that you’re absolutely correct - I left the by-note filtering in out of an abundance of caution; this really should be handled by-type.

Thanks for confirming, that’s actually was what I was hoping had happened.
With any luck I’ll get a small PR in tonight that should fix some issues for people with LP S, LP minis and APC minis. No promises though.

Sorry, no PR yet. But some good progress on a refactor towards sanity.

WIP at:

Currently Quad buttons don’t function correctly and more work remains to make many functions more “common” so they can be moved into base.lua

2 Likes

This may be a silly question but I’ve been toying with the idea of building one of the 128 button DIY neotrellis grids and I’m trying to figure out whether it’s a better plan to do that or buy one of the 64 button pre-built ones I see on ebay. How do you decide which grid is the right one for you? Does it depend on the applications I’m running on Norns?

I would definitely say yes to this, but also consider what you might be interested in in future.
My opinion/observation; the 128 seems to’ve become the standard. Most norns scripts I’ve seen are architected for 128, and the 256 isn’t even available anymore…

1 Like

Thank you so much for this project! I want to buy a Launchpad X, but I don’t see it among the supported devices, should it work properly or does it need some adjustments? Thanks