#61

I did only a few very quick tests some days ago with my Launchpad Mini (aka Mini MK2) and didn’t notice any issue but for now i’m waiting to have a case to protect my Norns Shield to use it/test more

#62

I started a wiki on the project to document issues with certain scripts and how to use the lib for scripts where the grids refrence is located in a weird location or requires some special implementation. Only layed out the bones so far will go and do all the scripts over the coming week.

2 Likes
#63

@Tim052 i just been checking your work on the github and the wiki, congrats!

1 Like
#64

getting these errors when using mg_128 :thinking:

stack traceback:
/home/we/dust/code/midigrid/lib/mg_128.lua:235: in method 'all’
/home/we/dust/code/awake/awake.lua:353: in global ‘gridredraw’
/home/we/dust/code/awake/awake.lua:207: in field ‘on_step’
/home/we/norns/lua/lib/beatclock.lua:79: in function ‘beatclock.advance_step’
/home/we/norns/lua/lib/beatclock.lua:86: in function ‘beatclock.tick’
/home/we/norns/lua/lib/beatclock.lua:28: in field ‘event’
/home/we/norns/lua/core/metro.lua:169: in function </home/we/norns/lua/core/metro.lua:166>
lua:
/home/we/dust/code/midigrid/lib/mg_128.lua:265: attempt to call a nil value (method ‘led_sysex’)
stack traceback:
/home/we/dust/code/midigrid/lib/mg_128.lua:265: in method 'led’
/home/we/dust/code/awake/awake.lua:356: in global ‘gridredraw’
/home/we/dust/code/awake/awake.lua:207: in field ‘on_step’
/home/we/norns/lua/lib/beatclock.lua:79: in function ‘beatclock.advance_step’
/home/we/norns/lua/lib/beatclock.lua:86: in function ‘beatclock.tick’
/home/we/norns/lua/lib/beatclock.lua:28: in field ‘event’
/home/we/norns/lua/core/metro.lua:169: in function </home/we/norns/lua/core/metro.lua:166>

no errors when using the midigrid 64 version?
with launchpad mini

#65

Ugh, yeah, there’s a not-so-subtle bug in there for non-Pro devices. I have a commit ready; I just need to find the time to push it :slight_smile:

1 Like
#66

Successful build!!!
But I have tried using the shield with my monome 128 and everything is perfect while it does not seem to work with my monome 64 (bibo boards, for the one who remember that DIY boards, basically seen as Arduinome)
is it not supported?

DIY: norns shield
#67

i can’t keep the clones straight in my brain. did bibio use an ftdi chip?

#68

They are based on an atmega chip so i do think so.
https://biboboards.bigcartel.com/

(It is bibo, not bibio…my bad sorry)

#69

You’ll need to track down some info to see how the diy grid is “presenting” itself on linux

First you need to see what tty device it is with something like ls /dev/tty*

Then - let’s say it’s ttyUSB0, do

udevadm info --query=all --name=/dev/ttyUSB0

Which will give you details on product/manufacturer which the norns software is looking at.

1 Like
#70

Thanks but I am not so proficient to know how to access linux on the Pi from my computer.
But very happy to learn if you can please share.

Sorry found it (ssh) but I do not know why I cannot do that on my computer , tried with another machine as well (beaglebone black) and cannot do it.

https://www.raspberrypi.org/documentation/remote-access/ssh/unix.md

Need to check this but I need a rest.

Thanks for the info
much appreciated

1 Like
#71

any idea on what the changes in code might be for this as launchpad mini is missing the relevant code? :thinking:

#72

2 new PRs up on the midigrid repo. #14 will hopefully fix the non-pro device issues.

#73

Confirmed: Looking at the PCBs there’s a 245R chip that is the FTDI chip

1 Like
#74

Thanks is anyone has an idea how to get the ones listed in the not working section going feel free to add to the pages. A lot of issues seem to come from scripts that have rapid blinking the launchpad has specific pulsing and flashing sysex commands i wonder if there’s anyway to leverage that to reduces the load on the lauchpad in scripts with lots of flashing objects.

@beepboop might be worthwhile updating the title of the thread and first post with the current state of the library now that it’s in a pretty good place.

1 Like
#75

:grinning: thanks for this still not working so changed mg_128 lines
237 to _brightness_to_buffer(note, vel, config.brightness_handler(vel))
267 to _brightness_to_buffer(note, vel, config.brightness_handler(vel))
342 to elseif (note >= 0 and note <= 120)
when using awake and most other scripts with 2 pages the leds do not refresh ie. they stay on from the previous page.

#76

I see from the Minis’ config that it uses a double buffer sysex (short-sightedness on my part - I completely forgot about the Minis). @JaggedNZ will probably have to address that; I’m sure I could figure it out, but I don’t have a mini to test with…

@martindunne; The idea there is that we’re pushing a sysex into the LED buffer for devices which use sysex. Your changes would try to push a brightness value into the LED buffer, which would at best have no useful effect.

#77

I’ll try to have a look at LP mini code in the next few days.

@Tim052 the flashing feature would be very application specific and there is no comparable grid feature. However it utilises the double buffer that I’ve already implemented for LP mk2 and LP mini’s, which improves things for suboptimal scripts like awake. The other thing that could be done is to use the update all led sysex but that’s good to require some rework of the code.

Is the code using the Norns grid buffer yet? Has anyone else looked at it?

I’d also love to pickup a second LP mini (dual LP for 128+??) but the new price here is fairly steep and the second hand units are rare and fetch a premium (could buy one of reverb and add shipping to New Zealand and still be better off) Direct message me if you think you can help. Thanks.

#78

Not yet, no.

Not that I’m aware of.

#79

just heads up that for for monome devices, most of the work happens in the C layer, including maintenance of the LED state buffer for each connected device. for midi-grids, i’d just do a similar thing in lua, but you won’t be able to reuse the monome-specific stuff.

#80

@zebra to be clear I’m talking about lua/lib/gridbuf.lua, not the internal grid buffer. It seems to be used by a number of scripts including some in monome/dust? I don’t want to start building on top of something that is deprecated, but on the flip side I think I can see a better implementation where we extend gridbuf.lua