SuperBrain (Multi Engine Midi Sequencer for grid & LP X)

currently not, but i will have a closer look at midigrid and maybe find a solution to have both, the new features of the new launchpad generation and the flexibility and compatibility of midigrid.

i will keep you updated, maybe I find time on the weekend … let’s see.

1 Like

Excellent - thank you very much!

This looks great!
Have you considered adding crow and i2c support for JF and W/synth? Could see this being a lot of fun with those included :sparkles:

sounds like a good idea, unfortunately I don’t have access to these devices. but I will have a look into it. i assume it should not be to hard if midi is already working.

I am still struggling with the midigrid library and how to enable support for more devices than the LaunchPad X.

Do you have access to a launchpad X and tested the script?

1 Like

Unfortunately I don’t have a launchpad x, just a grid or ableton push 2. I was going to see if the grid works.
Adding the options for JF, W/synth and crow should be relatively easy. There’s lots of great apps with clear code to see how it’s added.
I think Initnere or flora should have something useful to look at :slightly_smiling_face:

if you would team up on making it work for a monome grid, this would be super nice! I don’t own one, but already included the required code as comments. but it is not tested yet. so if you want to try it with a grid i can support you in do the code changes.

1 Like

I’m not the great at coding but I’d be more then happy to give it a shot. Especially if the codes in there and just needs to be in commented.

should be in theory as simple as uncomment line 16 and add comments to the both lines before

1 Like

I might as well give it a go! I’ll let you know if I get it working.


I made this script work with a 128 grid. The keyboard works, track selection and changing settings work. Though the sequencers don’t seem to be working, that or I just don’t know how to use SuperBrain. Here’s my fork GitHub - Quixotic7/SuperBrain at grid128

Also the lights for the side lights for the main engine area are lighting up in row 16 instead of 9.


Awesome to see someone working on a 128 of this. sweet sauce @Quixotic7

1 Like

SuperBrain is now fully working correctly with 128 monome grids! The sequencers weren’t working because the events being sent by the gridhandler didn’t match the names in the sequencer engines, which is likely a problem with people using this with launchpad.

I submitted a pull request. Added support for 128 monome grids. by Quixotic7 · Pull Request #1 · BeatRossmy/SuperBrain · GitHub

You can grab my version from GitHub - Quixotic7/SuperBrain at grid128

This could be improved further either by scaling the layout to fully utilize the 128 grid by adding support for 8 tracks, by rescaling the main area to take 8 rows for height and moving the isomorphic keyboard to the right, or by increasing the step count to 16, though then you’d need to use a shift button or something instead of the side buttons.

These sequencers are fun! I love how easy it is to change settings for a track, nice work @beat !


you are awesome, I would love to see a video of the script in action on the grid!

1 Like

I will give the code a review (only to see how you implemented the changes you were talking about) and then integrate it!

thanks again for the work, its is unfortunately quite hard to write code for the grid without a grid to test it with.

maybe i should jump on the train with the new grids?


I’ll make a video if I come up with anything that sounds cool.

I made it work by making a copy of your LP_X class called Grid128, so not much had to change. Working with the real grid is very similar to what you were doing, just you have x[1-16], y[1-8], and z[0-15], some of the z values were floating point which doesn’t work with the grid, so I rounded them.

The new grids look very tempting and cheaper! Unfortunately no velocity, but I find myself using my grid much more often than my Ableton Push because it’s small and sits nicely on my desk next to my mouse. I also like the look of single colors better than multicolor LEDs, it’s easier for me to see differences in brightness than different colored pads.

I was wondering how to enable users to switch devices automatically? maybe I can check if a grid is connected and then use your adaptions, and otherwise use the LPX.

I also like the ideas you mentioned to make use of the currently empty space, in case of a 128 grid. For some engines I think it would feel quite natural to even just scale up the width to fill up the whole space … I have to think that through since this would mean to find a way to make one and the same UI work on two differently shaped devices.

I am open for a discussion on that topic!

the reason for using floating point was to stay “consistent” or the least inconsistent with the grid implementation. I think here 0 is used for a key-off and 1 for a key-on event. so checking for 0 gives you the off event and in the case of LPX everything else is interpreted as velocity.

1 Like

To autodetect you could do something like this at the top of SuperBrain.lua

local midi_1_name = midi.connect(1).name

if string.find(midi_1_name, "Launchpad") then
  USE_GRID128 = false

It’s good the values were consistent to the 0-15 range, just needed to be converted to ints.

I found some usability bugs:
If I switch an engine on a track while playing, it doesn’t start the new engine until I stop and play again.

If I hold a sidebutton to change speed or something for the main section, it is muting it, so I change speed, then unmute. I think this could be fixed by only toggling on a release event and sending “hold_release” after holding.

Edit: This is because I shouldn’t have changed “clicks” to “press”, instead the problem is with grid_handler not sending these events. Reverting brain.lua and engines and looking into grid_handler.

Edit 2: Ok, I fixed this, engines now using the click and double_click events. In grid_handler.lua I increased the delta times for sending these events. It’s possible the clock changes in the latest norns update might have caused some timing issues when using clock.sleep but not sure. There still seems to be some problems with the grid_handler as sometimes the event will get stuck on hold. Though it’s better than before.

Edit 3: I didn’t see the variable for HOLD_TIME and which was shorter than the click time. I increased that and now it’s working very well. This grid event system is genius!

I am not sure if I understand what you mean exactly? HOLD_TIME is defined on the top of grid_handler

the click time is currently defined inline, here as dt < 0.1:

I didn’t see it the first time I was changing the click time in the code and had set the click time to 0.3 without changing the hold time, which was causing it to get stuck on hold. I ended up going with a click time of 0.25 and setting hold time to 0.3. This is working well.

I also just added dedicated buttons to the top right corner for the saving and loading presets and made them show overlays.

I am really amazed that are so comfortable with the code already!

I think regarding the UI exactly these cases show the dilemma of supporting a 128 and 64/LP layout.
On hte one hand I think it is a great opportunity to use the enlarged space, on the other hand the question is how to design for consistency between both devices.

@Quixotic7 could you send a sketch which illustrated the UI changes you implemented such as moving one of the rows to col 16? maybe this could help to figure out a way to keep both designs consistent and still make use of the larger space.

one thought was to make the areas larger. → cor LP you would have a 8x4 app and key area and fpr the monome grid a 14x4 area. obviously this would result in a less “western musical” step sequencer space in the case of graph^theory, but would not change the other engines to much.

I would further propose to make the first 128 grid column the top aux row of the LPX.