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
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.
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.
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.
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 !
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.
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 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.