default pset, and script-supplied psets

[tehn]

• make sure pset data from dust/code/SCRIPT/data get copied to dust/data/SCRIPT
• clarify default script loading methods--- call params.read(1)

[dndrks]

just some data points from Questions: https://llllllll.co/t/norns-presets-on-boot/33592/1

it's interesting that the growth of the ecosystem + userbase has made "default states" more attractive -- that when someone loads a script, they either want it to be how they last saved it or they want to define the re-load state. it sorta feels like a Nintendo Switch, where norns is the main console but you want to pick up where you left off in an individual game.

actually, thinking more about it, what if we offered a parameter class that persisted through reboots and reloads? sorta the way that a "fresh" session in a DAW doesn't require you to re-select primary settings. we offer this on a system-level, but it might be nice to let a dev define whether a parameter in their script is a primary performance setting (something a particular user might set to the same thing each time, though that "same thing" is different across users).

for example, i have a "MIDI control" toggle in a script which enables or disables MIDI messages being used for control over certain parameters and a "MIDI port" setting. i want my end user to be able to set those once and reload the script, or enter into new presets, without those parameters being overwritten. right now, i'm committing those parameters to a separate data file (which is rewritten any time one of those few parameter changes) and adding a 1-shot 100ms metro at the end of my init() to recall those parameters if the script it reloaded. it's a really nice feature, to be able to reload without having these settings i know i'll just re-set the same way being nuked.

[tehn]

cool! so we're talking about two issues:

1. definitely agree that some mechanism for auto-loading the last selected pset is smart. there isn't immediately a mechanism in place for this--- we'd basically have to write a new file in the data/script folder to save the last-loaded pset. i'd still want an explicit function to load the pset--- but perhaps a good syntax is no arg means load whatever was loaded last. rationale being i think there shouldn't be a whole lot of magic/unexpected behavior that could lead to confusion.

2. i'm interpreting this as a need for two tiers of pset. basically a global pset and a "numbered/dynamic" (currently) pset. this makes total sense. i'll introduce the third case (which was implemented in aleph) which is the "don't save this in the pset" flag for a param--- this is hugely effective for partial-list recall, which extends psets to a radically different use potential (ie, you can make a sequencer just with psets controlling a subset of params).

if each param had an additional attribute to specify its save-level (global, normal, off) we could navigate all this. i've hesitated in the past because it is an additional UI challenge.

[catfact]

maybe worth noting (to manage expectations) that since parameter actions are arbitrary functions, banging a preset doesn't necessarily restore state.