Norns: dust



Not at home to try it out but super curious: Does today’s update improve Norns MLR?


no updates to mlr today. just midi-cc mapping to its params.

mlr updates on my list next, thank you for your patience


Would it be crazy / annoying or overkill to start a norns mlr thread ? To help people clarify how to use it, ask questions and talk about potential features ?


Your Wish is My Command.


Markov melody generator (first-order but i’m ultimately heading for a second-order one). Interaction is a bit limited for now but it is just a foundation.

-- Markov melody generator
-- Key 2 randomize Scale
-- Key 3 randomize Probabilities = "PolyPerc"
Scale = {0,0,0,0,0,0,0}
Prob = {{},{},{},{},{},{},{}}

function init()
w = 1
noteSel = 1                                       -- note selector
counter = metro.alloc(count, 0.15, -1)

function redraw()
  for i=1, 7 do                                   -- Draws Notes
    screen.move(15*i, 6)
    for j=1, 7 do                                 -- Draws probability for each note
      screen.move(15*i, 10 + (j*7))
  screen.move(11, 9)
  screen.line(110, 9)                             -- Line
  screen.rect((w*15-1),8,4,1)                       -- Feedback

-- Counter
function count()
  engine.hz(midi_to_hz(60 + noteSel))             

-- Random Scale Generator
function rndScale()
  for i=1, 7 do
    if i ~= 1 then
    Scale[i] = Scale[i-1] + math.random(1,3)       -- Creates Scale{}

-- Random Prob Gen per note
  function rndProb()
    for i=1, 7 do
        remain = 100
        deck = {1,2,3,4,5,6,7}
        shuffleTable(deck)                          -- random distribution order
      for j=1, 7 do                                
        Prob[i][deck[j]] = (math.random(0, remain)) -- Mixup tables or last probs 0
        if Prob[i][deck[j]] == 100 then             -- Prevent 100% 
          Prob[i][deck[j]] = 99
        remain = (remain - Prob[i][deck[j]]) 

-- Midi to Hz
function midi_to_hz(note)
  local hz = (440 / 32) * (2 ^ ((note - 9) / 12))
  return hz

-- Prob roll
function probRoll()
local v = 1
  Test = math.random(100) 
    if Test > Prob[w][v] then
      v = v+1
        if v > 7 then v = 1 end
      x = false
    else x = true
  until x == true
  w = v
  noteSel = Scale[w] 

function shuffleTable(t)                 -- shuffle table content
    for ite = #t, 2, -1 do
        local shf = math.random(1, ite)
        t[ite], t[shf] = t[shf], t[ite]

function key(n, z)                      -- Key2 change Scale, Key 3 chang Probs
  if n == 2 then
    if z == 1 then
  if n == 3 then
    if z == 1 then


I’ve gotten started on this. Here’s a very early gist of a five buffer version.

Biggest thing I need to figure out a good way to do all notes off for only a particular buffer when stopped. Otherwise, exploring some interface changes and ideas, quantization of the loops relative to each other, and what the screen should do.

Here’s an early recording exploring seaaaa, cc mapping of various engine parameters with the nanoKONTROL2, and lots of delay, reverb and saturation.

Norns: help

hello_gong: the played notes seem to never trigger a note off, is this by design? Bonus question: how do I revert to the default parameter settings on a script, after saving my own configuration as default?


notes should be released upon note offs unless parameter amp gain is > 0.


I’m trying my first attempts at writing a small engine for my norns.
Maybe a stupid question but how do I actually put the file in the sc folder on norns?
Is it through maiden?
Or do I open a serial connection via usb and do it via terminal? And how would I go about and do that?


@AndersSkibsted this might help:


@jah quick question RE step. I’ve a gig coming up and I’d like to use step/grid for some drum sequencing. I know that I can save the state of the parameters menu, which is wonderful - is there a way to include the grid state?

I should probably say, I’ve not as yet even fired up Maiden etc, been too busy enjoying the scripts already written. I’m unlikely to have time to delve in either prior to the show (this weekend).


Not currently, but I want to include features for saving/restoring patterns too. Perhaps I can make a quick hack and include it as a parameter in the parameter set. When is your show? :slight_smile:


Oh man, that would be such a help. It’s sat eve (BST). Understand if it’s not viable or whatever, already feel in your debt for such great scripts.


Is there a way to pass parameter values declared within the norns interface to the CroneEngine upon startup/init of a script?


Noticed something in earthsea tonight while debugging a grid problem.

Seems earthsea is sending a gridredraw() twice in a row for grid_note() The first in the grid_note() function and then again in gridkey() where grid_note() is called.

Should we be wary of double/multiple refresh updates to the leds? I suppose this is a pretty benign thing though.



Something like “plane” or “nerdscroll”, where nearly every LED needs an update when any do, you don’t want to write unnecessary messages to the serial port.

But… If gridredraw() is checking a “dirty” flag, and thus only actually redrawing when something is changed, that shouldn’t add a whole lot of overhead.


in this case it’s checking for dirty, sending the LED frame, sending refresh, then doing both of those a second time (without having any changes occurred) - which I’m assuming is a bug.

EDIT: Clarification - I’m talking about the lua code here


I believe the low level grid code has dirty flags to avoid overhead.
(apart from the higher level overhead eg lua calls)


Try this out for pattern saved/bundled with parameters in the pset:

I won’t push this to the dust repo, as it’s not the ideal solution to have weird row1row8 parameters. i think i’ll try to add a pattern memory kind of thing (99 patterns or something) to the regular step script and a single parameterno parameter for selecting patterns.


this is probably a bug. gridredraw() goes through all of the code to draw the earthsea interface… so it’s burning cycles.

g.redraw() actually sends the grid data to the grid, conditionally if the grid pixels are dirty, and the flag is set when the pixels are written. not sure if the logic is smart enough not to set the dirty flag when a pixel is overwritten with the same value (pretty sure it’s not) so indeed i’d say earthsea needs a fix to be more optimized. works as-is, but should be fixed.