#1

EDIT: here is the new library that is being updated:

Sorry to not follow up for a while! But short story is that intercepting the vport connection itself in an external script, and then including that connection in the script itself, works very very well.
I dont have my code on me, but something like this is the ticket:

--lib/apcnome
--connect to the midi right here, before anything else
local apcnome = midi.connect()
local ledbuf = {}

function brightnessHelper(z)
  --parsing/filtering brightness values from 16 to 4...
end
 
function apcnome:led(x,y,z)
  --coordinate parsing to midi data
  z=brightnessHelper(z)
  for i,v in mididata do
    table.insert(ledbuf, v)
  end
end

function apcnome:refresh()
  self:send(ledbuf)
  ledbuf={}
end

function apcnome:all(val)
  ...
end

apcnome:event = function(data)
  ...note to coord stuff...
  apcnome.key(x,y,z)
end

--etc.
return apcnome

and then in the script:

...
--grid_device = grid.connect()
grid_device = include('lib/apcnome')
...

With something like this, to my surprise, I have quite successfully ported most grid apps to my dinky apc mini! I truly hadn’t thought I would be able to do this, I just wanted grid-like functions to do my own scripting on the apc, but it just started working and I pushed a little and now I am in a really good place using grid scripts without a proper grid.

Some scripts take a little fiddling, mainly because their connection to midi via midi.connect() will block out midi events coming in (even if the “grid” connection comes first). So I need to hardcode them to accept only the second midi device. OR if I am just looking for cc stuff with the apc sliders, then I can connect the midi to the same modified vport, and it just… works!

I even have a script that gives me two pages/views for my apc grid, which I can flip with two of the auxiliary buttons on the apc, and its almost seamless to use scripts meant for a 128 grid (nicely, I find, a lot of scripts–fm7, strides, shfts, vials–divide the grid in two and little is lost in this). I have a plan for mlr, which can utilize the auxiliary apc keys for the main nav buttons, and then spread out the four tracks horizontally on the 64 grid (or alternatively, just have an 1/8 resolution to the tracks rather than 1/16).

The only real problem with this approach is the aforementioned blocking of the midi device by another midi connection, and obviously only having four brightnesses on the apc (or rather, three colors and unlit).

This is perhaps a more meta question, but I want to eventually package and release this in the library, but I am not sure what I should do: either release all my ported scripts (with the small midi modifications) and the apcnome library/shim together ; or simply release just the shim scripts (both the one page and two page version) and give docs on how to use them. The way my script is set up, it should be trivial to change it for launchpads or whatever, everything is built off of just a two dimensional table of midi notes corresponding to the apc grid). The former I think would maybe be too much of a dump in peoples dust collection, but I don’t know if the library standards allow for the latter (just a script you need apply to other scripts?).

My one thought re vport is that it would be nice to have a different “class” of sorts for midi devices, that could by default somehow recognize it is being used in this kind of way rather then as a standard midi device (keyboard and cc-s), and which in this could block other attempts at midi connection with the device. Something like this would make what I am doing almost seamless (other than the brightness stuff). Otherwise, I am sure the community would love some built in support for apc/launchpad/midi-grids :grin:, which would be a simple as listening for connections with certain names and applying appropriate logic to the midi events in and out. But I totally recognize that’s probably a little too messy for such an elegant ecosystem as it stands, and would also maybe cause a lot of confusion. I am still thinking through, and will PR if I think I come up with something good.

EDIT Oh I see people over in the pi thread doing things similar! I dont see what the deal is with trying to be more sophisticated with serial connections… just using midi is great. I can push my apc so much and so quickly in just this way (as long as you buffer the midi data and refresh it like the grid). the apc will glitch a little sometimes… but I have had it before randomly setting 64 lights on and off at 250 bpm and it holds just fine. No need to be any more direct.

12 Likes
DIY monome compatible grid w/ Adafruit NeoTrellis
Akai APC40 hax
Fates - a DIY norns DAC board for Raspberry Pi
Norns: scripting
Hemisphere Suite Support
Beets 1.1.1
Approaching: norns
[cheat codes 2] (rev 210208: macros, transport, midigrid, midi config, w/syn, even more stuff)
[cheat codes 2] (rev 210208: macros, transport, midigrid, midi config, w/syn, even more stuff)
#2

Hiya! @beepboop Super interested in this!
Im for one im struggling with the serial connection of my midi device. @zebra has been very helpful pointing out that (i think) you approach could be one of the solutions to using the midi grid devices im trying to use with norns.
Im using a arduino leonardo that can also be configured as a midi device. I have two setups, an 88 grid and a 816 grid, that can be configured to be used as midi devices outputting midi notes.
There are pad with colors, just on and off leds.
The devices are the untz:
https://learn.adafruit.com/untztrument-trellis-midi-instrument/overview
It would be super helpfull if you wanted to share or have someone to test your scripts with other midi devices (midi grids) i also have a few mini launchpads to try.
Let me know if you want to follow the conversation via direct message or trough this post for general use.
Thanks for sharing :slight_smile:
Cheers

#3

hey! here is exactly what I am working with. I wont add this to the library because it has a lot of other peoples scripts in it and I forgot my gitignore. but if you look in the lib folder you will see the two scripts that I have made apcnome.lua and apcnome_2pages.lua. I have the former documented so you can see what I did, and change those top tables to suit your other controllers.

certainly would be great to have others test this so thank you! I just realized that I can offload my device specific configurations to another file, and then just include that in the main scripts and this will be much more portable. I am hacking away and will be updating and pushing as I do, so beware.

youll see I am hardly doing anything special here!

2 Likes
#4

Hiya! Thanks a lot for sharing this.
I have been looking into your code and it is very well explained, im going to map my controllers to the same midi note numbers as your apc and work from there.
Ill let you know how i get going, and maybe try with the launchpad mini, but for now im going to focus on the untz. I can see that you have already adapted many of the library scripts!
Thanks a bunch.
Cheers

1 Like
#5

I haven’t dived in too deeply to the above yet, but I just wanted to throw out that I made something similar for the older (red & green) Novation Launchpad:


Note: I have not tested this super deeply yet, and have only used this in a couple of my own scripts.

2 Likes
#6

Oh hey just a quick look and yours on first blush looks a lot less hacky than mine! Just in that it looks like you have solved the problem of the device being blocked by regular midi connections in a script, that it looks for the right device, and you have the cleanup and update_devices api in there.

I might borrow some ideas from this, if thats ok, and work towards a more generalized class. I imagine there could be like a single library script that has a config file of sorts to apply to different devices and styles of emulation.

Thanks for sharing!

1 Like
#7

Feel free to steal any and everything from it. PRs welcome too.

I get the impression from the above that you might be trying to solving the problem more generally, as well, which I am wholeheartedly in favor of, as long as it can be done without over-engineering.

#8

Hi!
Today i had some time to test your scripts.
I changed apcnome.lua to be used with Untz and with a launchpad mini.
The 9_grid lua script crashed with the untz, but works good with the launchpad mini.
I can use step.lua with the akay but its not working with the untz.
It seems like note on / off from the untz jam the scripts.
I have tested my unt with the midi tutorial here:


And it registers all midi notes on / off from the untz fine.
Wonder what its making it crash.
Cheers!

4 Likes
#9

Hi, so I extensively reworked my library, and I have configurations for both the apc mini and the launchpad, as well both the regular 64 grid emulation and a 2 page version.

To do the launchpad config I only referenced the manual, so it is untested. And if you want to switch between apc and launchpad, you right now have to comment and uncomment out the appropriate parts of script (either the regular or the 2 page):

local config = include('midigrid/config/apcmini_config')
-- local config = include('midigrid/config/launchpad_config')
-- local config = include('midigrid/config/untz_config')

Further, thanks to @license, everything should be a little more cleaner on the connection to midi devices.

I have stopped having altered scripts in this folder itself, as it just works in a given script to do this now:

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

So I am happy to have cleaned up my select screen. I, personally, still make copies of the script I want to use, but in the script folder itself, and add the new grid object.

@thopa what kind of midi information does the untz spit out? Namely, what are the midi velocities it spits out when you kit a key, and what velocity does it expect to turn on a light? If it is functioning as a midi device, this should be the only thing that needs adjusting, and then I can make a config file for untztruments as well.

If there is interest, I will see if this is appropriate to add to the norns library, but it can also live here! Once the launchpad is tested, I think this will be a sustainable and consistent library for people to use if they have the use case.

7 Likes
#10

Wow hats off! Going to test right now!

The untz just sends note on /off messages and receives the same.

The untz 8*8 note map is from top row to bottom row as on your local apcgrid script:

midi_notes

32,33,34,35,36,37,38,39
40,41,42,43,44,45,46,47
48,49,50,51,52,53,54,55
56,57,58,59,60,61,62,63
64,65,66,67,68,69,70,71
72,73,74,75,76,77,78,79
80,81,82,83,84,85,86,87
88,89,90,91,92,93,94,95

And the untz 16*8:

0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31
32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47
48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63
64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79
80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95
96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111
112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127

Testing now :slight_smile:
Thanks a lot!

update:

Ok so i have been testing this with my launchpad mini and the awake script.

*I have changed the midigrid.lua file to point to the launchpad_config.lua by :slight_smile:

–local config = include(‘midigrid/config/apcmini_config’)
local config = include(‘midigrid/config/launchpad_config’)

I then went to the awake script and modified:

local grid = include(‘midigrid/lib/midigrid’)
g = grid.connect()
–local g = grid.connect()

when i sent from maiden to the norns, i get this in matron as it seems to load ok:

matron_log

hs = include(‘lib/halfsecond’)

local MusicUtil = require “musicutil”

local options = {}

options.OUTPUT = {“audio”, “midi”, “audio + midi”}

options.STEP_LENGTH_NAMES = {“1 bar”, “1/2”, “1/3”, “1/4”, “1/6”, “1/8”, “1/12”, “1/16”, “1/24”, “1/32”, “1/48”, “1/64”}

options.STEP_LENGTH_DIVIDERS = {1, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64}

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

g = grid.connect()

–local g = grid.connect()

local alt = false

mode = 1

mode_names = {“STEP”,“LOOP”,“SOUND”,“OPTION”}

one = {

All

+1 of 2.*Aa\bS

matron

sc

norns.script.load(“code/awake/awake.lua”)

script load: /home/we/dust/code/awake/awake.lua

cleanup

script clear

including /home/we/dust/code/awake/lib/halfsecond.lua

including /home/we/dust/code/midigrid/lib/midigrid.lua

including /home/we/dust/code/midigrid/config/launchpad_config.lua

pset >> write: /home/we/dust/data/system.pset

script run

loading engine: PolyPerc

*i have checked the system-midi devices-launchpad settings on the launchpad and its selected ok.

*Now…if i go to awake-settings-output-midi, some of the launchpad lights work.

Im trying with your old step.lua but not getting any results.

I have restarted the norns, but unfortunately i cant get it working for now :frowning:

ok last edit!**

I finally got it working.

I had to change in the launchpad_config.lua file line 56:

device_name=‘launchpad mini 2’

Before it was saying just launchpad mini, so i guess this name needs to match the midi name of the devices that norns shows connected!

Many thanks :slight_smile:

1 Like
#11

ah yes I shoulda have mentioned the name thing, I wasnt sure about that, I should certainly fix it so its more of a fuzzier matching thing.

But I am glad you got it to work! Do the lights look ok on the launchpad as its mapped? The launchpads have much more variation in their lights so I would hope it looks even better.

Also, according to its documentation, launchpads accept some much more sophisticated messages than apcs, which could be taken advantage of. But I don’t have one, so it would be hard for me to develop/test.

I guess the main thing I need to know about the untz’s is what velocity messages are expected to turn lights on from computer to grid. On APCs and launchpads, different velocities directed to certain notes make different colors, and I imagine this is what is breaking your attempts to use the untz’s.

#12

No worries i figured it out late last night! Thanks a bunch :slight_smile:

With the launchpad mini i got it more or less working; when testing with the awake script, led feedback was working, and when pressing pads on the launchpad it would change the notes in norns, but unfortunately the leds would not stay latched on the launchpad if pressed.

The untz leds can only be on or off, so i was experimenting yesterday with the arduino to be bidirectional (for some reason it only sends midi notes but does not react to incoming midi notes to light up the correct led) so i made a sketch where usbmidi is read and if the note is on and its c2 or 0 then the light would turn on. If the midi message received was c2 or note 0 and midi note off then the untz led would turn off. And so on for each matrix.

I did that for the first 16 pads (1st row) but since im not good at coding i bet there are better ways of achieving this. Had to do lots of else if and case break, which i think its not the best way to do it.

So i guess the answer is that the untz responds to full velocity or none. 127 or 0, but as i have mentioned i was using a simple midi note on / off approach.

Ill do further testing this afternoon!

Cheers

Hi again, so im testing the step.lua script;
Im having the same problem as in awake, i can see the sequencer scroll in this case, i can input notes (the pads on the launchpad go red when pressed) but they dont latch, they are momentary.

Step plays the first sample loaded but only momentarily when the scroll reaches the pressed pad. if i for example press and hold two pads, its plays them sequenced as long as i keep them pressed, when i release they dont stay on as it should be.

Im getting this error in matron:

error

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

end

end,

refresh_callback = function(my_arc)

my_arc:all(0)

my_arc:led(1, util.round(params:get_raw(“tempo”)*64), 15)

my_arc:led(2, util.round(params:get_raw(“swing_amount”)*64), 15)

end

}

UI.init_grid {

–original

–device = grid.connect(),

–mod

device = include(‘midigrid/lib/midigrid’),

key_callback = function(x, y, state)

if state == 1 then

if cutting_is_enabled() and y == 8 then

queued_playpos = x-1

UI.screen_dirty = true

else

All

+1 of 1.*Aa\bS

matron

sc

no note found! coordinates… x:11 y:1 z:0

no note found! coordinates… x:11 y:2 z:0

no note found! coordinates… x:11 y:3 z:0

no note found! coordinates… x:11 y:4 z:0

no note found! coordinates… x:11 y:5 z:0

tutorial 9_grid.lua seems to work but the note latch instead of being momentary.

Ps: I attach the untz_config.lua file that i have created but its not working,
untz_config.lua (2.2 KB)

Thanks!

#13

meta mod note:

please use the [details] function in your posts when pasting large outputs, like this:

[details="big paste"]
lots of stuff here
[/details]

renders as:

big paste

lots of stuff here

3 Likes
#14

@thopa the launchpad problems sound kinda like the script is registering the midi note events and not the midigrid “key” events… Can you try putting the launchpad on a device slot different from 1? In the norns system menu.

All that said, I will have trouble developing for the launchpad or anything else as I have nothing to test with! Will certainly welcome people to do a PR on the repo if they troubleshoot and fix anything!

Also that config for the untz looks right, but I imagine if the untz only takes full 127 velocity messages to turn on the key, you need to change the brightness handler to something like this:

brightness_handler = function (val)
  if val == 0 then
    return 0
  else
    return 127
  end
end

Which just distinquishes key on and off messages. You have no brightness/color control there, so the best you can do is either turn them on or off.

#15

Hi @beepboop
Thanks for all the info :slight_smile:
I tried putting the launchpad mini in diferrent ports on the norns but it did not make a difference, button presses are read by norns but not forwarded back to the launchpad mini somehow.
I do have an older launchpad laying around somewhere, so im might give that a go.
Unfortunately i tried with the untz and with your mods but for now its not doing much at all :frowning:

1 Like
#16

Maybe this will be helpful, maybe not, but I remember from messing around with Max/Max4Live/Live with my OG Launchpad (and trying to do effective monome emulation) that the Launchpad requires messages from the host about what to do with it’s lights.
So, tldr; yeah, there has to be a feedback loop there.

#17

Hi guys did anyone try using their norns with a ableton push mk1? Got a norns on the way and dont currently have a monome grid…

#18

It’s hard for me to see from anything online at first glance, but if the Push can function as a simple midi controller, where it sends note_on/note_off messages when you press a button on the grid, and sending it note_on/off messages influences what buttons light up, then you should be able to use the midigrid library posted above, with a user defined config file that would just tell it what midi notes are what on the grid, and how to handle 1-16 LED brightness commands we get from scripts that use the grid.

#19

Definitely keen to have a crack at getting the Hella untz working ,it should arrive tomorrow with any luck. Just wondering what the Arduino is running for this to work ? I assume it’s just the adafruit code ?

#20

This might end up not being helpful at all… @technobear has Push 2 support in his fork of the norns code.