I just got a deal on a Launchpad Mk2 RGB will have a go at doing a config file for it when it arrives.

4 Likes

@beepboop got a layout for this working on the launchpad mk2 and have pushed it to the git. But there seems to be a lot of issues with scripts most seem very glitchy lots of unmapped key and no note found errors on vials and mlr. awake and earthsea don’t seem to like having buttons toggle values on and off they’ll either instantly turn off and or stay on or never turn off. I’m yet to find one that works aside from the most basic grid script. So not sure what’s going on but i think my layout is correct and i have the launchpad loaded in the second midi position.

Edit: unlike @thopa i am getting button presses being forwarded back to the launchpad

2 Likes

@Tim052 thanks for sharing your work!

@Tim052 Hey! I just merged in your stuff, so at least everyone else can look into it. Those issues are strange, but I do think it might be related to the actually much more sophisticated midi control for the launchpad.

Considering the future of this library (which I havent worked on very much, but still working well day to day for me!), I think the best thing going forward is to make the midi message handlers device specific, as callbacks in the config files. This way these issues can ultimately be resolved for different devices, while retaining the overall management of the device and the grid emulation itself in the main library, if that makes sense.

I wont really have time for a while to work on this because of holidays, but will certainly come back to this. also, you dont need to accept if you dont want (I see you already got a branch going now) but I went ahead and added you (@Tim052) as a collaborator on github so you can just be pushing new things if you figure it while I am gone.

1 Like

this is cool, wonderful work going on.
Will this work with LaunchPad pro? i hope

1 Like

Agreed. I have one on order, and I’ll be spending some time looking at this once it comes in.

Brain Dump, or: What I Did Over Winter Vacation With A New LP Pro

  • 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.
  • So I bought an LP Pro (got an incredible deal too…) After much fiddling and hair-tearing, I discovered that the ā€˜awake’ grid display spontaneously worked after:
    • putting the Pro in ā€œProgrammerā€ mode
    • specifically assigning the ā€œLaunchpad Pro 2ā€ entry to midi device 4 in fates[1] setup
    • completely removing the other two ā€œLaunchpad Pro" devices from fates setup
  • So at this point, ā€˜awake’ works perfectly as intended, except for the same behavior noted earlier above by @thopa; the keys don’t latch. however, I noticed that pressing two pads at once, then releasing one, then the other, results in the last one released staying lit. Note that there are no warnings/errors or really even any unusual loggings…
  • ā€˜9_grid.lua’ from the ā€œtutorialā€ repo works perfectly…
  • From the above, I surmise that there’s some weird interaction between ā€˜awake’ and 'midigrid’s key handling, though I am unable to see what it is yet.
  • ā€˜loom’ doesn’t do anything (with the grid), but I suspect that it requires a 128.

Unfortunately, I haven’t made any significant progress on the coding front. I wrestled with trying to get true RGB via sysex working, but my Lua/norns/Launchpad-fu is seriously underwhelming :slight_smile:

[1] I don’t mean to ā€œforkā€ here, but it seems to me that the differences between norns/fates are significant enough to be noteworthy

1 Like

Thanks to @ground_state for the feedback and work on getting this going.

Now that looks like a complicated set of options to get it going.

I dont recall having to use specific ports on the fates, i normally use port 1 as i think i have read that some scripts are made to work only on that port?

I might be wrong though…

So you are running into the non latching problem too!

Hopefully with the community joint work this can be solved :slight_smile:

Thanks for your input!

1 Like

From what I understand, monome grids are fully automated, that is to say, in this context, there’s no need to use port numbers at all.

OTOH, MIDI devices do have specific ports assigned to them, which a script will need to know about. It seems to me that most script writers assume a pretty straightforward setup, i.e. a single MIDI device, auto-assigned to the first available port - #1 – thus the port 1 thing.

The problem for us is that auto-connecting to the device on port #1 could potentially conflict with the MIDI grid which is there. I mean, technically we are using it as a MIDI device, but our goal is to use the grid API.

1 Like

I expect to start poking into this thread and the repositories soon! (And reread everything here more carefully…)

i have a Launchpad Mini mk2 (an old OG LP too, the very first one released by Novation, the one that requires a driver).

@beepboop, I have a PR up for LP Pro support

cc specifically @shreeswifty - you can try it from my repo branch

@thopa, @Tim052, @zproc, and even @license - If y’all wouldn’t mind reviewing/testing, it’s PR #2 in beepboop’s repo.

1 Like

FWIW - behavior here should be identical between norns/fates. If you’re seeing something different I’d love to hear more about it.

Also - Monome device ports (should) work the same as midi - you can assign them where you want. It’s just most scripts default to the first slot.

I do see issues swapping between devices where they auto-populate into the norns slots/ports and then I need to clear them out - don’t have a specific thing here that goes wrong though (that I remember)

I haven’t seen anything specific, given the level at which I’m working (tldr; the differences are below the Lua level for sure) – it’s more like I feel that specifying which platform I’m on constitutes ā€œfull disclosureā€ in case it ends up being an issue.

Having said that, fates > norns if only for bluetooth audio support :wink:

1 Like

BT audio is not a thing I like but have used this guy with norns when necessary

I have set up bz audio stack on pi and on factory norns (with dongle) and just didn’t see the point in either case. It’s fiddly, not very reliable, boot time is faster with BT services disabled, kernel has less work to do, etc (ymmv of course)

Sorry for OT but kinda had to say that

1 Like

I don’t disagree at all. BT is a bitch to set up under linux. I just like being able to play around with the fates w/out any wires at all :slight_smile:

If I were doing anything serious, I’d use my good AKG cans for monitoring + line out for recording

Sorry, I don’t have an LP Pro to test, just an OG Mini.

Oh, sorry, I wasn’t clear; I made some large-ish changes to the codebase, so it all needs testing :slight_smile:

Ah, gotcha! OK, I can’t promise I’ll get to this immediately but I’ll report back if I find anything with it.

1 Like

Done some testing seems to work on the mk2 using sysex commands and seems to solve the latching issue but casues scripts that use grids to fail to launch if no launchpad is plugged in i’ve got the full error on the github pull request.

Then went and tested it with a all the grids scripts i know of here’s a complete list of working not working seems like the vast majority are working.

List

working scripts
earthsea
awake
boing
earthbound
Ekombi
foulplay(kow refresh rate)
glut
loom
medow physics
mlr
molly the poly
orca
punchcard
mangl
shfts
step
strides
timber
timeparty
traffic
vials
zellen

not working
playfair
cheat_codes
cranes
fm7
isoseq
less concepts(call led function fail)
strum(roatiom)
takt

1 Like

Hi all, I am still out of town/mostly away from computer, but just want to say its exciting to see this work happening! will be back to looking at this soon.

@ground_state I have merged your request now! those refactors and the launchpad pro config is now in the main branch