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.
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
lua:
/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:
boot up a terminal on your laptop
connect your norns to WiFi
in your terminal: ssh we@norns.local with password sleep
in your terminal: nano ~/norns/lua/core/paramset.lua (or vi or whatever terminal text editor you prefer)
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 --
save the file (in nano: ctrl+o then enter) and quit the editor (in nano: ctrl+x)
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)
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 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.
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.
UPDATE:
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:
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.)
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.