norns: update 220129


norns 2.6.1

  • FIX intonation lib, make lamonte monotonic @catfact
  • NEW numerous improvements for desktop compilation @winder
  • NEW tabutil lib, add select_values @nattog
  • FIX softcut optimizations @catfact
  • FIX pset writing order @catfact
  • FIX mods, handle no matching @ngwese
  • FIX build options for desktop @catfact
  • NEW tabutil lib, add gather @ryanlaws
  • FIX ensure favorites exist prior to load @tyleretters
  • NEW password entry within SYSTEM menu @tehn
  • NEW watcher pw reset touch /boot/norns.txt @tehn
  • FIX verbose missing engine message @dndrks
  • NEW script rerun shortcut norns.rerun() @tyleretters
  • NEW lattice lib pattern delay @schollz
  • NEW sequinz lib peek @tyleretters
  • FIX screen message for jack fail @tehn
  • NEW musicutil roman numeral chord generation @Dewb
  • FIX link adopt tempo when joining @Dewb
  • NEW clock param to enable/disable link start/stop sync @Dewb
  • NEW system update download progress @tehn
  • NEW tilt support for grids @okyeron
  • FIX screen png-display @tehn
  • FIX lattice lib patterns pulse in order based on id @schollz
  • NEW link transport activation from norns @schollz
  • FIX crow clock consistency @sixolet
  • FIX param name collision @dndrks
  • NEW CPU profiling tools @catfact

maiden 1.1.5

  • NEW full light / dark theme @dansimco
  • FIX various styling improvements and increased contrast


  • NEW update libmonome, improves grid stability @trentgill

Normally have no issues at all with updates but getting error: init on Awake as an example. Restarted and powered off. Seems others are having trouble with splnkr after updating too splnkr v0.3.0 - #61 by DoS

Interesting; Awake is working fine for me; but I’m also getting error: load fail on Colorwheel and error:init on Constellations (this is the first time I have run the latter; the former was working fine for me before the update). Just got error:init on Takt and Reels too.

A random selection of other scripts run as normal: Circles, Buoys, Breakthrough, Flora, Glitchlets, o-o-o, Supertonic

I put the Norns Shield to sleep and hard rebooted after the update.

1 Like

I can confirm the error: init issues. seems related to many scrips re-using system param IDs:

here’s the maiden output for Awake, for instance:

# script init
### SCRIPT ERROR: init
/home/we/norns/lua/core/paramset.lua:122: paramset.add() error: id 'output' is already used by another parameter
stack traceback:
	/home/we/norns/lua/core/norns.lua:145: in function </home/we/norns/lua/core/norns.lua:145>
	[C]: in function 'error'
	/home/we/norns/lua/core/paramset.lua:122: in function 'core/paramset.add'
	/home/we/dust/code/awake/awake.lua:256: in global 'init'
	/home/we/norns/lua/core/script.lua:126: in function 'core/script.init'
	[C]: in function 'xpcall'
	/home/we/norns/lua/core/norns.lua:146: in field 'try'
	/home/we/norns/lua/core/engine.lua:91: in function </home/we/norns/lua/core/engine.lua:89>

and here’s Colorwheel:

### SCRIPT ERROR: load fail
/home/we/norns/lua/core/paramset.lua:122: paramset.add() error: id 'track active 1' is already used by another parameter
stack traceback:
	/home/we/norns/lua/core/norns.lua:145: in function </home/we/norns/lua/core/norns.lua:145>
	[C]: in function 'error'
	/home/we/norns/lua/core/paramset.lua:122: in function 'core/paramset.add'
	/home/we/dust/code/colorwheel/lib/algebra.lua:21: in global 'dequeue_param_group'
	/home/we/dust/code/colorwheel/lib/algebra.lua:73: in main chunk
	[C]: in function 'dofile'
	/home/we/norns/lua/core/startup.lua:42: in function 'include'
	/home/we/dust/code/colorwheel/colorwheel.lua:14: in main chunk
	[C]: in function 'dofile'
	/home/we/norns/lua/core/script.lua:192: in function </home/we/norns/lua/core/script.lua:192>
	[C]: in function 'xpcall'
	/home/we/norns/lua/core/norns.lua:146: in field 'try'
	/home/we/norns/lua/core/script.lua:192: in function 'core/script.load'
	/home/we/norns/lua/core/menu/preview.lua:23: in function 'core/menu/preview.key'
	/home/we/norns/lua/core/menu.lua:143: in function </home/we/norns/lua/core/menu.lua:120>
# script clear
ERROR: paramset cannot nest GROUPs
ERROR: paramset cannot nest GROUPs
ERROR: paramset cannot nest GROUPs
/home/we/norns/lua/core/clock.lua:59: bad argument #1 to 'resume' (thread expected)
stack traceback:
	[C]: in function 'coroutine.resume'
	/home/we/norns/lua/core/clock.lua:59: in function 'core/clock.resume'

i might recommend that the error call on line 122 be reverted, and instead it have it just print a debug warning with instructions to contact the script maintainer.

for those looking to resolve this issue for their devices, I did the following:

  1. boot up a terminal on your laptop
  2. connect your norns to WiFi
  3. in your terminal: ssh we@norns.local with password sleep
  4. in your terminal: nano ~/norns/lua/core/paramset.lua (or vi or whatever terminal text editor you prefer)
  5. go to line 122 (where you see a line starting with error("paramset.add() error, and comment it out by prefixing the line with two hypens --
  6. save the file (in nano: ctrl+o then enter) and quit the editor (in nano: ctrl+x)
  7. in the terminal: sudo shutdown now to shut down the norns

many apologies for the trouble— we had no idea that so many scripts were overwriting param names, which itself introduces various other bugs (which prompted the name enforcement), so if your script does this, please fix it.

please report not-working scripts here (just a name will do). i can help fix any problems (and if anyone has time to help tackle the list, please jump in)

i’ve fixed awake. get the new version in maiden. (if you want to see how easy it was, i simply renamed “output” to “out” as seen here)


@21echoes no need for the white button. just ssh back in and type sudo shutdown now — too much white button can corrupt your filesystem.


@jaseknighter’s flora is not happy with the update. error: init

i’ll look into the issues with flora and splnkr in the next few hours.


i’m strongly of the opinion that this should remain an error message. clobbering system parameter IDs produces serious bugs (and corrupted/unusable preset files,) and it is an easy mistake to make, i think it’s actually a kindness to developers to make this fail fast and hard.

if we need to temporarily make it a warning to give people time to fix their scripts, i guess that’s fine.

(but yes, this change should have been more prominently mentioned in the release notes.)


that makes a lot of sense :pray: knowing the number of users who are very scared of editing scripts, i wanted to offer a path to “the way it was” for them, because i bet most script maintainers will not release fixes for some time. but yes, definitely agreed that being strict about fixing this sooner rather than later is definitely better for the health of the ecosystem.


i bet between us on this thread we could very easily PR the necessary trivial changes for all affected scripts. (just needs renaming of colliding param IDs.)

if somebody is feeling altruistic and looking for a coding challenge, one could even do this programmatically.

i too am surprised that so many scripts are affected, so a scraper / searcher script might be warranted anyway.


i’ll get updated and check through my scripts, happy to help fix others as well :slight_smile:


working through my scripts this morning, and i came across a weird one. showers is throwing an init: error for the id “thunder”…


Engine.register_commands; count: 12

___ engine commands ___

rain f

rain_damp f

rain_decay i

rain_dry f

rain_hpfreq f

rain_lpfreq f

rain_spread f

thunder f

thunder_damp f

thunder_decay i

thunder_dry f

thunder_spread f

___ polls ___









script init


/home/we/norns/lua/core/paramset.lua:122: paramset.add() error: id ‘thunder’ is already used by another parameter

stack traceback:

/home/we/norns/lua/core/norns.lua:145: in function </home/we/norns/lua/core/norns.lua:145>

[C]: in function ‘error’

/home/we/norns/lua/core/paramset.lua:122: in function ‘core/paramset.add’

/home/we/dust/code/showers/lib/showers_setup.lua:57: in field ‘init’

/home/we/dust/code/showers/showers.lua:15: in global ‘init’

/home/we/norns/lua/core/script.lua:126: in function ‘core/script.init’

[C]: in function ‘xpcall’

/home/we/norns/lua/core/norns.lua:146: in field ‘try’

/home/we/norns/lua/core/engine.lua:91: in function </home/we/norns/lua/core/engine.lua:89>

edit: i wonder if this is because i have a parameter group named thunder? if so, should that throw an init: error? i wouldn’t think so. it does :slight_smile:

I was similarly confused by colorwheel throwing for "track active 1", but didn’t have time to dig in more…

can’t have a group name be the same as a param name. i ran into this with awake. it makes sense, in the long run— please take our word for it that all this fixing now means less fixing with bug reports when other parts of the param system don’t work. we should’ve had the system enforce this a long time ago.


I had a failed updated of sorts on my norns shield (latest version of hardware from monome). Updated from SYSTEM>UPDATE. Rebooted after waiting for the non-red light to stop blinking. Unit restarted but the green light was on solid for about 20 minutes. Unplugged and rebooted (nothing showing in maiden). Rebooted and everything seemed fine until a second reboot that just flashes the green light quickly twice and then nothing.

Is there a way to read this card (maybe from another norns?) before reflashing? I’d like to grab some save data.


I was able to save the data from the SD card and re-flash. So far so good. Not sure what happened. At one point in the failure it booted to “jack fail” on the display.

this is just an idea, but could there be a choice of what update you choose? so if there are issues you could easily flip back to the previous version until stuff is fixed.


The sdcard should be readable by inserting it into any other Linux machine (Pi or otherwise). If using Windows or macOS the following post might be of value:

1 Like

After a full re-install (imaged with etcher and then updated over Wi-Fi), I installed the “moonraker” script. After a bit, the OUT and IN audio meters became stuck totally maxed out. I did a SYSTEM>RESTART and ended up with a “Jack Fail” on reboot.

A full power cycle brings it back to functional.

I did get a “Jack Fail” before the norns became unbootable in post above.

assuming its a shield, seems like a good time to check SD card and soldeding on the header / codec. journalctl might yield better information about why jack is failing (and might not.)

i don’t believe this update would do anything that would affect the ability for jack to boot. it simply introduces the more specific error display when jack fails (as opposed to “supercollider fail” which now really does mean what it says.)