norns: update 220129

yeap; up to you but might be nice to check for that and display something informative rather than

yeap, this is weirder but it is something to do with require, it’s not correctly searching for absolute paths on my system for some damn reason.

require is a built-in lua system that is complicated and sometimes does counterintuitive things (e.g. around caching.) for something distributed within your script’s lib folder, definitely recommended to use include instead (this is a function we made, which is not as “smart”, but ends up being more portable, case in point. using ‘require’ you lose the benefit of bundling the thing with your script - you no longer reallly know which version of the thing will run, or when it will run)

ok really no more debugging for me sorry. i know this test is not awesome but it’s what i could do quickly. i’m now testing (on norns) the rather trivial htofix to revert this err to warning. (while, i am hoping, also providing a more robust failure state than pre-update - viz., refuse to add the param rather than clobbering.) then i have to crank on something else for a while.


thanks so much for continuing to dig in on this!

have merged reversion to main

new update won’t happen for a few days. if you are in desperate need of the “fix,” you can pull it down from main (its a small change to lua files, no compilation etc is needed)

you can enter this into the matron REPL if you wish:
os.execute("cd ~/norns; git pull")
followed by ;restart.

in this change:

  • system parameters are not clobbered. this means if your script declares an output_level param, that parameter will no longer work. we find this preferable to breaking the main output level control on the mixer page and so on. (we saw very few instances of this particular issue; one or two may yet remain in the wild.)

  • script and mod parameters are clobbered. this means if your script declares a param ID twice, or declares a param that is already declared by a mod, the first one will break. this is the same as the pre-update behavior, just with a scary warning now.

  • neither case causes a load error.

little note: it is the parameter ID field that matters; the parameter name field (display string) can be whatever. i’d encourage mod authors to try use unique prefixes for parameters added by the mod. long cumbersome ID strings are fine.


Thanks so much for the tips and advice (and the pull request). I’ve merged the pull request, and I’ll fix the other one when I get a moment. Appreciate you taking a look <3

So sorry to ask such a dumb Q , but I can’t figure out what’s going on :grimacing:

Is there something we’re supposed to be doing re this update?
I know there were issues with Flora and splnkr for example, but they are resolved.
I just tried to open Colorwheel and got the error: load fail message.
Are we waiting for the respective script creators to amend something? Or waiting on a broader fix?

Again, sorry for my ignorance


TL/DR: navigate to http://norns.local, enter these two lines in the matron REPL, and all scripts should work again:

os.execute("cd ~/norns; git pull")

[uhh caveat: this is assuming you haven’t done any “special” developer stuff with your norns. e.g. if you have cloned norns via ssh and your ssh key is passphrase-protected - mine is, of course - then this command will fail; you need to ssh in and pull from there.]

in this update, we introduced a new error message to catch a potentially serious class of bugs in scripts, mods, and/or script+mod combos.

in most cases (there are not actually that many), the fix is extremely easy. but when mods are involved it does get more complicated. so we just reverted the error to cause a warning instead. this reversion is not yet in an update, but can be applied through git as shown above. (or can be performed locally quite easily as @21echoes demonstrated further above.)

(this change should have had a beta period. we messed up on that.)

@yams FYI, here are the colliding parameters in colorwheel.

creating group track 1 with 28 params
adding 28 params
!!!!! error: parameter id collision: track active 1
creating group track 2 with 28 params
adding 28 params
!!!!! error: parameter id collision: track active 2
creating group track 3 with 28 params
adding 28 params
!!!!! error: parameter id collision: track active 3
creating group track 4 with 28 params
adding 28 params
!!!!! error: parameter id collision: track active 4

this is not a super serious instance of the bug and may actually be benign (because only internal parameters are being smashed, and maybe the smashed versions are identical to the smashees) but it is also not the simplest fix for me to just PR (since the parmeters are programmatically generated.) (in any case i do recommend avoiding spaces in parameter ID strings, BTW)


Mine updated without any problems. Nice


Hmm… I updated without any problems until I went to add a new script today and realized I can no longer connect to maiden through my browser or terminal like I usually do. Anyone else have this issue?

Not currently, no; but I may have done after the first time I updated (or this may have happened later), so I just disconnected the wifi and logged back in and Maiden started working again.

1 Like

Yeah, tried that. Still doesn’t seem to be working.
Screen Shot 2022-02-07 at 5.01.00 PM

1 Like

did you try explicitly connecting to norns IP address? (shown on home screen of norns UI; press K2 repeatedly in menu)

if you can connect via IP but not resolve norns.local, next step is maybe flushing DNS cache.

Thank you so much! All it needed was a good ol’ flush! Back in action!


A post was merged into an existing topic: Fates - a DIY norns DAC board for Raspberry Pi

hey everyone, hoping someone can help me out. I’m unable to connect to maiden at all, neither norns.local nor my ip are working. I tried redownloading the update and that hasn’t had an effect. I flushed my DNS cache as well. I can’t connect through file explorer either. I’m assuming that it isn’t a hardware issue since I was able to download the update. any help would be greatly appreciated!

Did you check that you were connected via WIFI?
Recently, I restarted my shield after adding a script and lost Maiden contact after that. Turns out some reason it never reconnected to WIFI. Once I forced it to sign in, everything was fine.

yep, I even removed the wifi address I normally connect to and then re-added it. I’m assuming I’m connected to wifi since I was able to download the updates.

Can you ping or SSH that address?

Does the address ping when the norns is off?

just tried pinging and it said destination host unreachable. I’m confused though, because I think I would have to have some sort of connection to download the updates.

any change that you might have two different channels on the go in your house? I have a 5g and a 2.4 on seperate (but identical) logins… funcitonally from day to day, I owuldnt notice this as i move about the house and my laptop etc just picks the better one… but my norns and laptop need ot be on the same one to link up.

My desktop is connected to the 5g band through ethernet, and norns is on the 5g through wifi.

1 Like