TL/DR: though it is a fine idea in theory, consider that adding an “extension” is really the equivalent of just running a patched version of ~/norns/lua that is unaffected by updates. for pretty obvious reasons, this is an undesirable option compared to (A) submitting the patch upstream if it has widespread utiltiy, (B) confining it to a script if it is niche, and IMHO should be a method of last resort.
we are cautiously building out some mechanisms for global customizations in lua via a .matronrc. the primary reason for this is to more gracefully support hardware customization without patching the norns system sources. but other global behaviors may make sense there as well.
the caution is important - @infinitedigits as you’ve implied, too much of this kind of thing impinges on the efficacy of the platform as a known quantity against which scripts can be developed and shared.
e.g.: you may start with adding a preamble for total save/recall of parameters and softcut buffers, but sooner or later you may want to programmatically effect these actions from within a script. now the script can’t be shared without caveats. [“it could break things sometimes” is not a very good thing to have to say about a new feature.]
i’d instead ask whether the behavior is a good candidate for global inclusion by merging it upstream; in this specific case we seem to be steadily extending the amount of stored state per script in any case, so your efforts may well be appreciated there.
in other words,
if the answer seems to be “yes,” then the best action is to consider just bringing the feature upstream. for exampe @andrew, arc behavior in the issue you reference is very obviously (to me) something that should just be a part of the main norns system, to be evoked when an arc is attached - and that of course is why it’s on the issue list. (IOW, i don’t see the value in forcing the decision on how the arc interacts with parameters onto the user. and on a technical level, we already have a default arc handler that arc-aware scripts must override - we are simply proposing a more useful behavior than a no-op for the default handler.)
it may interest you all to know that startup.lua was initially conceived (by me, maybe not by everyone on the project) as the place where custom startup behavior would happen. (but i also assumed that scripts would be much less monolithic.) that would still be the place to shim in things that you want to execute in a clean lua environment, with all processes alive but before event loop starts ticking.
clearly, there is no technical obstacle to explicitly executing logic from ~/dust there, or before script init. instead it’s an ecosystem design consideration which leads to dependency management and many more potential support challenges. (think about, i dunno, Skyrim mods or something.)
so, my personal opinion is that in the abstract i think it’s a fine idea to support something like ~/dust/data/user.lua, but support for norns is already challenging and we arguably rely too much on the willingness of users to engage in very technical troubleshooting steps, so pragmatically i think a conservative approach is correct. and since the heavy lifting of support is being done by monome HQ team, this kind of decision is theirs to make.
