#284

For Norns the recommended procedure now is to use the ;install command in the input bar at the bottom of the screen in Maiden.

;install https://github.com/jaggednz/midigrid - but I’m not sure if that works as I installed it by ftp, which isn’t recommended these days.

3 Likes
#285

That ;install method should work, please let me know if it does, I have not had a chance to test it.

@DoS im curious to know which scripts where too fast for your launchpad? A lot of my work on midi grid was to try replicate the grid buffering done on a low level by Norns to get the speed up. I think most of the animation tests in Okyerons grid test script work and they are pretty severe, though I could be miss remembering, it would be nice to know what doesn’t work to help optimise, either the midi grid code or the scripts.

Life and other projects are getting in the way of hobby dev time at the moment…

2 Likes
#286

I was wondering if you’ve gotten this to work with Arcologies by chance. I’ve been playing around with the bit of code I’ve needed to edit in other scripts, but for some reason I get an init error if I add in midigrid. I’ve messed around with keeping the functions local vs global as well, and seem to get different flavors of error.

That said, I also wanted to say thanks for the library, it has allowed me to try a bunch of stuff I wouldn’t have otherwise, and is a heck of a lot of fun to integrate when I can.

Also, can confirm that the ;install method works just fine.

1 Like
#287

HUGE thanks to you and @DoS for your patience and suggestions - I’m happy as the proverbial pig in clover to report that I have, finally, got the midigrid repo installed. :grinning:

Next is to add the line to a script to test my shiny new Launchpad - ‘Awake’ has been suggested - and hopefully… crosses fingers

I’m making notes and screengrabs as I go so am hoping to post a n00b’s how-to guide a bit later, but for now, I have to get washed, dressed, slurp prodigious amounts of coffee and boot up the work computer. Yay dayjob!

Thanks again to both of you, as a non-coder & not-very-technical person, I really appreciate it :green_heart:

2 Likes
#288

Not sure why people are having issues with Arcologies, but I did have to remove and re-install it to get the latest version (this is after playing with it to add midigrid to the old g.lua)

On the latest version edit lib/_grid.lua
For a single lp / device:

_grid = {}
local grid = include "midigrid/lib/midigrid"
g = grid.connect()

For a dual launchpads / two devices:

_grid = {}
local grid = include "midigrid/lib/mg_128"
g = grid.connect()

I’m really curious to see how device support changes in the near future in Norns, and actually there are a bunch of changes in the last update I have not had a chance to review either. I suspect that to progress further and get the older launchpads to work as well as I would like I’m either going to have to deep dive into the linux drivers or some serious hardware hacking (launchpads with a RP Pico brain?)

Please do share any documentation you feel is needed, I’m happy to add it to the project.
Thanks for all the feedback, and being part of the line community :blush:

2 Likes
#289

I had to do the same and then added the same code fragments you showed and it’s working fine again.

It’s mostly been what I imagine are CPU-intensive grid-based scripts; I’ll go through each one and let you know wheich I’ve found to be slowest so far, though kolor probably has what I’m assuming is the most latency, with button presses taking many seconds to register. Gridtest works perfectly, for instance, as do all the various awake varieties, and so does beets.

1 Like
#290

Incoming clueless n00b question klaxon…

What does error: load fail mean and how do I fix it?

I edited the awake script in maiden to add the midigrid include lines mentioned above and the error appeared when I restarted the Shield.

I originally tried with just local grid = include("midigrid/lib/midigrid") and the error appeared, shut down, restarted and added the upper line _grid = {}. Restarted, same error.

Attached screengrab shows my trail of destruction in the script.

midigrid_install_3
midigrid_install_3889×275 28.8 KB

I’d be very grateful for any suggestions as to how to fix it!

Edited to add: Here’s a screengrab of the error dump:

load_fail
load_fail957×595 79.9 KB

#291

Hey Helen,

You don’t need the line “_grid = {}” that is specific to another script, and @JaggedNZ was showing that to explain where in the code I needed to make edits.

With awake, you can use the instructions outlined on the midigrid github page.

In my device, the code I have to start the grid in awake is as follows:

local grid = include(“midigrid/lib/midigrid”)
local g = grid.connect

I am at work now, but can verify that when I get home. Give that a try though and see if you get the same error.

2 Likes
#292

Hey @funkoftherob :smiley:

Thanks for that - I had tried only local grid = include(“midigrid/lib/midigrid”) first time, and got the error.

Added _grid = {} and tried again, same error.

Have taken both lines out now and it’s back to working normally, no errors.

Bit of a headscratcher! :thinking:

Edited to add: Tried with grid-test:

Added local grid = include(“midigrid/lib/midigrid”) to grid-test.

matron returned this error: midi inconsistency for device: Launchpad Mini MK3 2

#293

Quick initial thought while not in front of my Shield - is the Launchpad Mini plugged into one of the Shield’s 4 USB ports or via a hub?

#294

Direct to USB, no hub.

I’ve switched around among the USBs on each shutdown/restart - there have been a few!) so have had it plugged in on (I think) 3 different ones so far.

Edited to add: I’m looking at the core.lua script (midigrid/core.lua at master · miker2049/midigrid · GitHub) and although I have absolutely no idea what’s going on, I’m vaguely wondering if there’s something in the supported devices section needs looking at more closely:

function midigrid.init()
    local supported_devices = {
        apcmini = 'apc mini',
        launchpadmk2 = 'launchpad mk2',
        launchpadpro = 'launchpad pro 2',
        launchpad = 'launchpad',
        launchpadmini = 'launchpad mini'

Does it, do we think, need something like this adding?:

launchpadmini3 = 'launchpad mini mk3'

Anyway, that’s enough for me for one day - 8pm here in London after my usual 5.30am start - and I think my brain’s about to starting leaking out of my ears…
Thanks everyone who’s chimed in so far, it’s so great to know there are others who are interested in the problem-solving side of it all.

1 Like
#295

@ngwese any chance you can explain what might trigger the “midi inconsistency for device” ? My limited low level C skills fail me. Is this triggered by a flood of midi events or a flood of midi connect events?

@helen you might want to try a powered usb hub if you have one.

I’m not sure I’ve stated this here but I strongly recommend a powered usb hub if you are using more than one device as lighting all the LEDs will cause low voltage drop outs on your pi/Norns

1 Like
#296

I’m afraid I don’t have a powered USB hub - I’ll have a look online and see what’s available (is there any minimum spec that would be useful?)

The Launchpad is the only other device I’m planning on using with the Shield - audio input would be most likely from whatever synth’s headphones or line out direct to Shield’s audio in so wouldn’t be expecting the Shield to power it.

#297

pretty weird one…

the only thing that pops out to me is that this loop index is a uint8_t, and it is compared with a ssize_t. if there are >256 bytes in the buffer then that could get borked in the loop comparison and/or the result comparison. (why would there be such a huge buffer in one read cycle? idk. systex?)

might be worth changing uint8_t i; to ssize_t i; here:

1 Like
#298

I can see one or two things which should get buttoned up in the code (such as also bounds checking the against the buffer the individual bytes are being written into, currently only 128 bytes). Regardless during development I was never able to generate buffer sizes even remotely close to 128 bytes in size even while hammering norns with sysex data dumps from other devices USB devices.

The error message was intended to indicate that some multi message MIDI data (such as running status or sysex message) was interleaved with a MIDI data that is not allowed during those multi message transmissions. Another possibility would be a device sending running status or sysex then disconnecting in the middle. The current logic will completely toss the contents of the ALSA/kernel level MIDI receive buffer if the contents seem to be corrupted in an effort to get back to a known good state. Of course this assumes that the norns level code for handling incoming MIDI is bug free…

I can take a closer look this evening when I have more time (unfortunately I don’t have access to one of the targeted midi grid devices so I’ll be flying blind to some degree).

UPDATE: one additional thought is that maybe the device is sending “active sense” MIDI messages and those are not getting handled correctly. Will have to find something which emits active sense here.

…if this is something which is happening then it is within the realm of possibility that this could trigger the inconsistent midi data errors.

1 Like
#299

Looking in /we/dust/code/midigrid/lib/devices/supported_devices.lua, this is what I see there:

local supported_devices = {
midi_devices = {
{ midi_base_name= ‘launchpad’, device_type=‘launchpad’ },
{ midi_base_name= ‘launchpad mini’, device_type=‘launchpad’ },
{ midi_base_name= ‘launchpad mini mk3 2’, device_type=‘launchpad_minimk3’ },
{ midi_base_name= ‘launchpad mini mk3 2 2’, device_type=‘launchpad_minimk3_128’ },
{ midi_base_name= ‘apc mini’, device_type=‘apc_mini’ },
{ midi_base_name= ‘block 1’, device_type=‘livid_block’ },
–[[ Known devices to be implemented, help required!
Old launchpad mini’s have user set hardware ID 1 - 16:
e.g. ID 4 appears as midi_device.name “Launchpad Mini 4”
{ midi_base_name= 'launchpad mk2 ? ', device_type=‘launchpadmk2’ },
{ midi_base_name= ‘launchpad pro 2’, device_type=‘launchpadpro2’ },
{ midi_base_name: ‘launchpad mk3’ device_type:‘launchpadmk3’ },
]]–
}
}

The issue here might be that you need to install the repo at https://github.com/jaggednz/midigrid, which is the fork that @JaggedNZ has got working - I was never able to get the original miker2049 script working with the Launchpad Mini Mk3.

1 Like
#300

active sensing should be ignored by norns midi.lua.

I have keyboard that sends active sensing if something needs testing/confirmation

2 Likes
#301

Your right, looks like there is some missing code from my branch to support mk2 and MK3 devices. I’ve found the code on someone else’s fork, I will try merge it later today.

I think the midi inconsistency error is a red herring in terms of getting the device in question working. From memory the later launchpad devices present multiple midi interfaces some are used for standard midi and some for other things (ableton live?) I suspect the error is triggered by one of these other interfaces.

1 Like
#302

Yes, this is exactly right - hence this in /lib/devices/supported_devices.lua:

But maybe I added that (edit for clarity: to my local copy of supported_devices.lua) myself? It’s been a while since I got this running and I’m now confused.

1 Like
#303

Wow, a massive thank you to @zebra, @ngwese, @DoS, @okyeron and @JaggedNZ for taking the time to look into this and batting ideas around. Most it goes waaay over my head but I think it’s still safe to say you folks are awesome!

For me, now, the things I need to do are: uninstall whichever repo I installed at the start then reinstall @JaggedNZ’s later (after the code update/merge) - and get hold of a powered USB hub in the meantime.

Thanks again for all the care and attention you’ve all put into this, it really means a lot.

Update: I’ve ordered this powered USB hub:

https://www.amazon.co.uk/Powered-RSHTECH-Charging-Portable-Splitter-Red/dp/B07RK3S4KF/ref=sr_1_3

…and this (not cheap) USB-B to USB-B cable to connect Shield and hub, because (a) I don’t have any B-B cables, got almost every other flavour, and (b) it does fast data transfer:

https://www.amazon.co.uk/C2G-Metre-Cable-Speed-Transfer-Black/dp/B00436GQN2/ref=sr_1_53

Both should be here tomorrow (Friday) so here’s hoping they do the trick…

1 Like