#121

ah, didn’t even notice that. thanks

still getting load error though

5
51533×658 44.8 KB

I don’t know if either of these would help show what I’m missing:

6
61519×608 52.2 KB
7
71524×621 54.2 KB

Maybe that’s the problem. I don’t have a “mg_64.lua”
I only have mg_128 & mg_256 that i grabbed from the miker2049 midigrid repo
anyone know where i can find that if that’s what i need?

Damn, it worked. I just changed 64 to 128. i’m an idiot. but i guess if there is a “64”, i should grab that

thanks again for the help man, you made my day. i appreciate that a lot

EDIT: I just wanted to put this here in unlikely case that someone with a launchpad pro and a newly built fates wants to get MLR working and has the same problem I did deciphering the install instructions and also has no knowledge of coding. this is what the working script looks like for me:

Working MLR64 Script Code for Launchpad Pro
Working MLR64 Script Code for Launchpad Pro1573×752 44.3 KB

3 Likes
#122

If you git cloned the miker2049 midigrid repo, you could just do a git pull to refresh it.

If that makes no sense to you, then I’d suggest going to the miker2049 midigrid repo main page at GitHub, clicking on the green “Clone or download” button, selecting “Download ZIP” at the bottom of the popup box, copying the download over to norns, and unpacking it in your existing directory :slight_smile:

2 Likes
#123

There is no mg_64.lua that I know of.
@encephalitislethargi did you find this in a document? I’m trying to locate all document I suspect are soon going to need updating again… :slight_smile:

For defualt 64 button mode:

local grid = include(‘midigrid/lib/midigrid’)

1 Like
#124

Goodness. That must’ve been some copypasta madness on my part. I don’t know how that crept in there…

#125

While we are on the topic, would the following syntax be more clear:

local grid = include(‘midigrid/lib/midigrid’)
grid.init('128')

I’d definitely be leaving stubs in mg_128 and mg_256 for backward compatibility.

Also, I have machinations to create a script that would “patch” midigrid deep into the Norns core, with a big “warranty void” sticker on it, my thinking is you would not need to modify each script. You would need to re-patch after each upgrade and theres a risk of breaking Norns updates depending on how they are performed. I might see if I could get a PR merged into norns if I can make it clean enough… Thoughts?

I’ve been having some health issues (nothing serious) so my progress on OOP midigrid is much slower than I would like, but I’m getting tantalisingly close …

P.s. Does anyone have any idea’s on how to remove ballpoint pen marks from launchpad / silicone buttons? Warm soapy water helped but did not completely remove.

1 Like
#126

Ouch :frowning:

Oh, that’s very nice.

Yeah, this was always in my long-range vision… unfortunately (hah), I built a neonome, so my need for midigrid kind of went away. I’m still interested in helping out, though :slight_smile:

#127

Ouch :frowning:

That’s the risk of buying s/h I guess. It’s not bad luckily, straight line across one button, I might have noticed it on the auction listing otherwise. Certainly better than paying local retail prices :crazy_face:

unfortunately (hah), I built a neonome, so my need for midigrid kind of went away

Yeah, I wish I could justify joining that party :slight_smile: Though I keep looking at the card edge connector / programming interface on the launchpad and wondering …

1 Like
#128

That would make sense, thank you.

And no I didn’t see mg_64 in any documentation. I was just missing the first “include =“ line initially

#129

at a much earlier point in norns development i assumed that systemwide lua components would be customizable. for good reasons, we avoided encouraging this so far. but it would be very simple to say, always run ~/dust/code/startup.lua if it exists, on boot, for injecting global customizations. (~/dust will never be touched by updates.)

the downsides are pretty clear: if one were to use global customizations, it would require some discipline and care to ensure that you are never changing behavior of scripts you intend to share. (brian will probably hate me for mentioning it.) but hardware shims would be a canonical use case.

1 Like
#130

the downsides are pretty clear: if one were to use global customizations, it would require some discipline and care …

This is why I’m hesitant to patch into core, as it doesn’t take much to totally brick things and the users most reliant on it are likely to be the least able to resolve the issue; even reflashing is an “undertaking” for them.

hardware shims would be a canonical use case

Maybe if hardware shims could register themselves via a “startup.lua”, then they could be appropriately wrapped in error handlers like params and scripts are?

TBH I’m sounding things out before I even have a working implementation.

On another note, are USB device ID’s surfaced at the script level at all? … I think there might be an appropriate Midi Cc message I could use if not, but I need to survey devices to see what supports like.

#131

you mean VID/PID? no… but small manufacturers and DIY devices don’t have them anyways. or do you mean something else?

currently, scripting layer gets a name, an arbitrary enumeration number, and an opaque device pointer.

the name includes a serial number for monome/crow/&c, and for MIDI it is a concatenation of card+device+port index reported from ALSA.

#132

Yes, VID/PID, looking at some of the launchpad line, they may use the same device names for different models (launchpad gen.1 vs gen 2) based on some of the feedback here :expressionless: and the current scheme doesn’t account for the port index (easy fix though).

I was thinking instead of blindly trusting the device name I could query deeper. It looks like Launchpads respond to an undocumented* sysex Device Inquiry (Sysex 0x06h 0x01h) which might be a better device identifier, falling back to midi name for devices that don’t respond or are unrecognised.

Any new or DIY device is going to need to be implemented via a new device config/definition, unless it behaves like an APC mini (is there a better default behaviour?) and my aim is to make this as easy as possible.

*Undocumented in the launchpad programmers reference

#133

We can certainly add glue for lua to query vid/pid if that is helpful.

#134

Milestone 1 of the rewrite reached!
LEDs on and buttons responding … on multiple devices! Yes, I have two Launchpad mini’s working as a single 128 grid.

Remaining features / Known issues before “Alpha” release:

  • Support CC buttons (e.g. top row of launchpad)
  • Support Aux button features (e.g. right column of launchpad)
  • Page switching (Should be pretty straightforward)
  • Some LED update latency issues to track down (generally surprisingly fast)
  • Don’t lockup the system with errors when a device disappears / unmounts
  • Need to redo redraw process to support same page on multiple devices (i.e. draw quads not devices)
  • Device un/mounting (might need to hack the core Midi implementation :expressionless: )
  • Move devices folder inside lib (and make all paths relative?)

I’m having somewhat expected issues with voltage dropout with multiple devices, so I need to sort out a powered USB hub.

Alpha release will likely only support launchpad mk1/S, launchpad mini and the APC mini, but it should be trivial to add new device support! and only tested with Launchpad Mini.

Code is public here, if you are feeling adventurous. Things will likely break if you try it. :wink:

Does anyone have any objections to me labelling this as midigrid v2.0 ?

12 Likes
#135

20 characters of :flushed:

I do not.

#136

This looks great! Am I right in understanding that the original Launchpad works with this? I was under the impression it could only be used with Ableton but I am very much interested in using it with Norns if possible.

#137

Honestly the launchpad lines “versioning” is a mess. I think I can say that the Launchpad S should work, but I’ve read that the original launchpad has had issues with the driver. This means there might be issues at play that midigrid can’t resolve, but I’d be happy to help assist in a least giving it a good shot.

p.s. I’ve yet to implement “fast led” update for Launchpad / LP mini, this will be implemented as a seperate device, so the “raw midi” version can be easily selected, but the default implementation might not handle high FPS / large updates well. That said I seem to be achieving much high FPS that I expected!

1 Like
#138

IIUC based on what seemed like reputable research I read online, the original original Launchpad can’t respond quickly enough to a realtime kernel to function properly. However, as JNZ says, the LP versioning is indecipherable, so really the only way to know is to try :slight_smile:

1 Like
#139

Thanks for your effort. I have an apcmini – purchased for this purpose. Worked previously, but with upgrade, and after I added reference to this device at line 27 of midigrid.luna, I am not getting the following error

SCRIPT ERROR: load fail

/home/we/dust/code/midigrid/lib/base.lua:51: attempt to index a nil value (global ‘vgrid’)
stack traceback:
/home/we/norns/lua/core/norns.lua:126: in metamethod ‘__index’
/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…)

I will figure it out, but thought I would post this.

#140

Please use mg.lua not midigrid.lua
I will do this rename shortly