do not worry about it unless you are also encounting an actual problem.
Hi,
I’m encountering scripts not loading on my Norns Shield (n191106). I just updated to v220321. I keep getting this message in Maiden on any script that won’t load (they seem to hang in the loading stage)
m.read: /home/we/dust/data/demoncore/demoncore.pmap not read.
It’s particularly strange though as Demoncore (for example, it’s happening with lots of scripts) opened fine about 5 minutes previous to this and I haven’t done anything in the meantime to make this happen?
I’ve tried flashing SD/fresh install, updates etc, but I keeo running into the same problem
when a script is loaded, norns tries to pull up any existing MIDI mapping previously made for the script. if there’s no MIDI map file, then it won’t load and those messages will print to maiden. these messages are not an error, just a report that norns has not located an existing MIDI mapping file for these scripts – it is not indicative of any reason for hangs. @zbs recently added a bit more detail to the message to help soften its appearance: Update pmap.lua · monome/norns@cf3be6c · GitHub
if a script cannot load, it should print additional information to maiden to let you know the cause – if you share any additional messages, we can help identify the trouble!
I’m now experiencing every script I try to start failing silently (i.e. no further matron messages) after giving a pmap not read error… this is just after an update to 220321, but before the update I was beginning to experience it - when I had a script set to launch on startup (it was dronecaster), it started up fine, but trying to launch anything else exhibited this behavior. (And now I seem to have unset that launch script and am launching to the main menu with NONE. )
this isn’t an error, it’s just a message informing that a saved .pmap file was not found for the script (which is normal on first installing any script). so don’t worry about it.
(sidebar: what are .pmap files? when are they created?)
parameter state data on norns consists of a PSET and a PMAP. there is one of these active on the system at any time:
the PSET describes the set of all parameters that have been added by system/scripts/mods. the description of each parameter includes name, range, curve, mode, (etc), and current value.
the PMAP describes zero or more connections between controller inputs and parameters. the decsription of each
for each script, the system creates at least one .pset and .pmap file to save and restore the configuration of the script. additional files can be written through the PARAMETER and MAP menu functions. the defailt .pmap is written automatically under several conditions: a mapping is added or changed, a PSET is written (this is sort of arbitrary but there you go) or explicitly from UI. since a default .psetis written when unloading a script, a default.pmap` is also written when unloading a script, and it is empty if no mappings are added.
so the behavior you’re seeing sounds normal in itself:
you flashed the latest image sometime before the 220321 update, removing all saved .pmap files.
you ran dronecaster, then ran something else. when you ran the second script, dronecaster was unloaded and a default .pmap file was created (at ~/dust/data/dronecaster/dronecaster.pmap.) it’s an empty file unless you added MIDI mappings.
if you are adding MIDI mappings for a script, and then seeing this message the next time you run the script, then that sounds like an error. it’s not an error i’ve encountered so i’d need steps to reproduce.
as for getting script NONE, this is normal after using the SYSTEM>RESET command or manually deleting ~/dust/data/system.state. if you think you are getting to that state in error, please try and share steps to reproduce.
i recently noted with another user experiencing trouble with state persistence, that they were regularly using SYSTEM>RESET instead of SLEEP to shut down or restart norns. don’t use RESET for any reason except to recover from a script that has put itself in a bugged state. it explicitly does not “save your work.” SLEEP is the only way you should be shutting down norns in normal operation.
this isn’t an error, it’s just a message informing that a saved .pmap file was not found for the script (which is normal on first installing any script). so don’t worry about it.
Well, but nothing is getting past the loading... screen and actually starting. I think you’ll agree that that’s not normal.
i agree that it is not normal for no scripts to load. i am informing you that the one data point you shared is not an error message and does not help me identify the issue. maybe you could share additional output from maiden.
to be honest, from your post it was not clear what “failing silently” meant. "stuck on loading..." is a little clearer.
# script clear
### cleanup failed with error: /home/we/dust/code/fm7/fm7.lua:610: attempt to index a nil value (global 'pat')
# script load: /home/we/dust/code/goldeneye/goldeneye.lua
including /home/we/dust/code/goldeneye/lib/Sample.lua
including /home/we/dust/code/goldeneye/lib/config.lua
including /home/we/dust/code/goldeneye/lib/_grid.lua
including /home/we/dust/code/goldeneye/lib/functions.lua
including /home/we/dust/code/goldeneye/lib/filesystem.lua
including /home/we/dust/code/goldeneye/lib/samples.lua
including /home/we/dust/code/goldeneye/lib/graphics.lua
# script run
loading engine: Goldeneye
>> reading PMAP /home/we/dust/data/goldeneye/goldeneye.pmap
m.read: /home/we/dust/data/goldeneye/goldeneye.pmap not read.
# script clear
# script load: /home/we/dust/code/foulplay/foulplay.lua
### initializing data folder
# script run
loading engine: Ack
>> reading PMAP /home/we/dust/data/foulplay/foulplay.pmap
m.read: /home/we/dust/data/foulplay/foulplay.pmap not read.
That’s all the output I see from backing out from fm7’s loading screen, selecting goldeneye, backing out from the loading screen, and selecting foulplay. That one error from fm7 is the only one I’ve seen, and it doesn’t seem super related. Is there some log file that might have more info?
Reset took care of the delay in starting foulplay, but I think I’ve found the culprit and I can’t believe it didn’t occur to me: launching @infinitedigits ’ new acid-pattern script. Sorry for bugging folks when I’d gone off the paved roads. derp
There was never anything that I caught in the sc scroll - I don’t think it was getting as far as spinning up engines? Who knows.
Reset took care of the delay in starting foulplay, but I think I’ve found the culprit and I can’t believe it didn’t occur to me: launching @infinitedigits ’ new acid-pattern script. Sorry for bugging folks when I’d gone off the paved roads. derp
There was never anything that I caught in the sc scroll - I don’t think it was getting as far as spinning up engines? Who knows.
yeah that looks like it has plenty of ways to hang the system. i won’t go down that rabbit hole except to note that its probably cricital to foillow the readme regarding external dependencies to install through shell commands.
if it was my new script that was causing @misuba error - I am sorry! I just shared the script in the study group discord and didn’t intend it to be utilized much. I put a huge “beware” banner on it now cause it does have rough edges that still need smoothing. if you do want to play with it and run into problems, feel free to hmu about it and I can work it out with you.
@zebra I’m sorry if this little script caused some support burden here, it will be cleaned up before I share it anymore. your help is always always appreciated, I can’t say that enough.
I was having similar issues with some other scripts and a system:reset cleared things up. I believe it was tapedeck that threw this error with the “loading…” loop, but others have done it previously. I cannot recall what scripts they were, realizing this is a wider issue than just for me, I will make better notes and share them here if the issue comes up again.
)