Norns: dust



I’m facing the same issue – how to store grid sequences – in my norns script experiments.

I’d like to try out this idea in a future version of my AWAKE script experiment to reduce the number of parameters that are to be saved when saving a grid page. I want to turn grid page (i.e. 16 steps with 9 values per step, as each steps LED’s are either off or 1 of its 8 LEDs is lit) into one large integer number. E.g. 9000300090309357 gives full velocity on steps 1, 9 and 13, lower velocity on steps 5 and 11, and increasing velocities on steps 14, 15 and 16.

As far as I understood this post, norns can display integer numbers with up to 20 digits, but the leftmost number would be only either 0 or 1, and the one right next to it could only go from 0 to 8, which leaves 18 digits that can each cover the whole range from 0 to 9.

This should work, no? Or am I on the wrong path?


Imo sequences / patterns are better saved in other ways than shoe-horning them into one or more number parameters like I did in my posted stepmod gist above. It’s certainly possible and the end result above is a pattern bundled with other params in preset/pset files. But I think we should come up with better and more general ways of storing/restoring such data structures along with psets. For instance, these pattern data numbers show up and are editable in menu > parameters which is plain wrong since they’re not really meaningful as params.

I guess the current alternative is to write data out as files and read data from those files (like in the latest playfair script in dust). There’s no way to trigger read/write upon switching psets, however, so afaik you can’t really bundle data structures with psets this way.

I’ll create a github issue and suggest a couple of ways this could be handled by extending norns functionality (callbacks, extending psets, or something else)


An integer can not begin with a 0.


I’m using bitwise operations to save booleans/trigs in numbers in my posted stepmod gist. But I would suggest to look at playfair pattern saving instead.


Agreed, these pattern numbers don’t make that much sense to be displayed & be editable in norns’s parameter screen.

But even if such data structures are not to be displayed as (potentially meaningless) parameters in norns’s PARAMETER screen, I think these data structures (like tables) should be stored/recalled as part of parameter sets, so that the currently existing user-accessible methods for in norns’s PARAMETER screen (save/read pset 0-99) can continued to be used, and give a “complete” user experience, i.e. storing/recalling a pset does not just store sound-defining parameters, but also sequence-defining tables.


Just last night I hacked together a pattern reading script which is built on jah/stepmod.lua but I am handling the patterns by reading from a data file.

In short - it pre-loads a patterning into step.

I’ve got something mostly working with known drum samples in common/ and using a data text file formatted like this:


When the script loads, all the patterns get split read into a big array - ideally I can make a way to select the patterns.

The patterns load into the grid step sequencer and you can then change the patterns from the grid as you would normally with step.lua

I went this was because I was pretty confused by @jah 's bitwise operations/number storing and I thought it’d be easier to read a pattern with a set of 0’s and 1’s.

Saving and loading patterns by name are my next tasks.

EDIT - I asked this over in the scripting thread, but I’ll ask here too:

What kind of data can be stored with params:set()?

I could not figure out how to store a string. The docs could use some more love in this area.


I’ve successfully done it this way:

params:set("1: sample", "example.wav")

assuming the engine is expecting a string


Right… but this appears to be a param from the SC engine - which is already established for the number of sample channels/tracks available.

So - I can read/write to those params for each “channel/track”, but I don’t see a way to create a new one that is a string. params:add() just threw errors at me.


ah gotcha. not sure then (not in front of norns). the latest study doesn’t explicitly mention strings but this might work?

lastly, we’ve been using the default parameter set throughout, but we can create as many of our own parameter sets as desired. they won’t be hooked up to the system menu, but we can manipulate them in all of the same ways. here’s how to create one:

others =

this creates a new parameter set called others and adds a number.


Thanks – for the time being that looks like the right place for me to store my sequence data as parameters without having these confusing numbers show up in the system menu.

Does anybody know if these “invisible” parameters sets will be stored/recalled along with the standard pset, i.e. if I store/recall the standard pset via norns’s PARAMETERS screen, will a potentially existing others.pset also get stored/recalled behind the scenes?


the type accepted by params:set() depends on what parameter you’re referring to. so a file parameter (added by params:add_file()) will accept a string representing a file path, a number parameter (added by params:add_number()) will accept an integer, and so on.


OK - that’s making sense.

However, params:string (index) is pretty baffling. It only takes an index? and then I am unable to set something to that index.

params:string (1) -- create a string param
params:set(1, "my new string to store")


lua: attempt to compare string with number


Right. For clarity (you probably know this, but for those new to programming, lua, norns or those just interested). All #: sample parameters are file parameters. They’re added in the ack lua module (here: ack.lua) which may be require d in scripts (like so: playfair.lua). The ack lua module contain a couple of helper functions to add engine parameters commonly used in the PARAMETERS UI. It’s possible to disregard the module completely and invoke engine commands directly.

ack has some docs with a section about Ack Lua Module:


In addition to engine params it’s of course possible to create custom, script specific params and add them to the default paramset. The easiest way to do this is to use params:add_control(), params:add_number() and so on. For instance the step script has swing amount param added in the script: step.lua

There’s no standard norns param for arbitrary string use right now, only file params representing file paths with file selector functionality. You may use this to store strings but that’s not its intended use.

All standard norns param types are here: . In the Object Oriented Programming sense these are classes which are instantiated and added to a paramset when add_control/number/etc() functions are invoked, such as params:add_control(). In the OOP sense paramset is a class and params is an instance of that class used for the PARAMETERS UI.

Which, uhm, gets us to params:add(). This is a special case function only used in core norns code at the moment. The function can be used to add param instances. *

local polyphony ="polyphony", 1, 12, 6)

* Advanced: Lua is dynamic. It’s likely possible to create your own, custom param types, instantiate and add them to paramsets by creating your own number, control or file so to speak (like a string param) and add it using params:add(). As long as your new param type adheres to the interface used by params they’ll work. But I’d advice against this, and try to rely on standard norns params for the moment. Or create a new param type and PR it to the norns repo.

…long, late night post, not sure if this clears things up :slight_smile:


The string() method is not used to create a string parameter, but used to retrieve a string representation of a given param.

There’s not much documentation on this, so it’s understandable you run into these issues.

The underlying problem to solve: to save additional state (such as a lua table) in a pset along with other parameters is not well supported yet, but something I think we should consider. I’ll create a github issue for this shortly.

EDIT: here


I have a non Varibright 128 and was wondering if its posisble to adapt some if the scripts that require them (hello_ack, step) to work with my setup.


Earthsea and/or Polysub bug?

With a midi controller attached to earthsea, sending a note number larger than 64 will result in the note not sustaining. I get an attack, then the note drops out and then comes back on at release. Everything seems normal below note number 64.


first thought is that sounds like the filter envelope is sweeping past nyquist and blowing up (or something)

looking at polysub, its a little wonky, final cutoff hz should be clamped after here:
[ ]

worth a try


I just created an issue to add support for non-varibright devices to step. In practice this amounts to displaying the playback position at maximum led level. (i have a non-vari grid to test with)

hello_ack should work right now except that the backlight of the row of buttons referring to channels are not lit. Note that my hello scripts are very rudimentary - kind of like “hello world” scripts showcasing an engine.


Should be technically possible. Some apps will require more rethinking than others, though.


In a quick review of the Ack info in github, it looks like there was a start on supporting a gate for that engine, but that it was commented out. Any chance of getting that working? It’s the perfect engine to support some of the stuff I want to do with single cycle waveforms (ala and dedicated delay effect, but I need more control over gate time that trig gives me.

@jah Might this be possible? Even probable?

Approaching: norns