Is there a way to retain reverb parameter settings after reset?

I’d like to be able to retain my reverb setting and not have to reset them or load PSET on every boot. Is there a way to modify the default levels of the reverb?

1 Like

20 characters of bump …

previously the mixer levels were not save-able or mappable, so by universalizing the params the reverb is now state-connected to the pset system.

one underutilized feature is for scripts to load the last used pset.

param.load()

with no args this will grab the last-written-or-read param for the script. which i think should solve most musical use requirements.

if a script uses psets, this line should be in init somewhere.

5 Likes

quick bump, @distropolis : deep in the noodles + release notes of yore, it was originally planned that rev/comp parameters should also save as part of system.state, so that they could load at their last state without restoring a PSET (since some scripts don’t use 'em).

gonna take a crack at adding this in rn

1 Like

That would be great! Thanks!

not sure if Im posting in the right topic here, but every time i start my norns i need to turn the reverb off. is there any way around this? I tried restarting and it doesn’t retain the setting.

1 Like

What version of the Norns OS are you running?

it’s supposed to, so that would be a bug. i can’t reproduce it. reverb setting is saved and restored if i power off using the SLEEP menu command, or if i perform a soft-reset using RESTART. other ways of turning norns on and off are not recommended for general use. in particular:

  • hard power cuts should always be avoided and of course will interfere with state persistence
  • you’re not using the RESET command by chance? that doesn’t perform a normal reboot, it’s intended for forced recovery from a misbehaving script; among other things it wipes out all the audio settings in the system.state file (see below).

i also took a moment to re-examine the lua and C code mechanisms which govern the effect state. things have become a little convoluted but the mechanism is clear enough and seems to be working as intended:

  • the file ~/dust/data/system.state contains the reverb settings and is saved independently of any script.

  • the relevant line of this data file looks like norns.state.mix.aux = N, where N is 1 (reverb off) or 2 (reverb on.) changing that value should change the enabled state at startup.

  • i do see that the system default (if system.state is deleted) is to enable reverb. not what i would choose maybe, but there you go. you can change the default in this line of code:
    [norns/state.lua at main · monome/norns · GitHub]

(but that is part of the system scripts and will likely be wiped out on next OS update. anyway it shouldn’t be needed.)


hm couple other things to check off:

  • it is possible for a script or mod to override the system-persisted reverb settings. (is there a particular script you’re working with?)

  • maybe you’re hearing some other reverb/delay effect? (just checking)

@distropolis – latest update, just checked.

@zebra – yep, doing SLEEP and/or RESTART. nope not using the RESET command.

no particular script i’m working with. i’m relatively new to this so I’m still exploring different scripts. it seems to persist regardless. no other reverb/delay within the script parameters in the edit screen or outboard on my end.

i haven’t edited any system scripts yet so i’m a little hesitant (just have been doing the firstlight lessons).

it’s quite inconsistent. i just did SLEEP and it did work.

yeah sorry, i’ve just been unable to reproduce. i’ve now done ~30 trials on two nornses, using SLEEP and RESTART. in every trial, the following is all true after boot:

  • visible parameter state matches the audible processing state
  • both those states match with the visibl/audible conditions before sleep/restart
  • same value is stored in sytem.state file.

i also did examine all relevant code and cannot formulate a theory to explain any software bug around this. the only theories i came up with seem unlikely: like perhaps the disk is out of space or otherwise unwriteable. (sporadically?)

the next series of questions would be standard ones about: whether you’re using standard norns or shield, if shield then , and in all cases can you share logs (either by copying matron REPL output as early as possible after boot, or b y using the new SYSTEM>LOG feature and sharing the resulting large (~12MB) logfile directly.

but at present i’m not able to treat this as a norns software stack issue.

1 Like