Scene and settings saving utility

Recall is a utility for saving anything from presets, scenes, buffers and anything else your script uses to disk. Developer can pick between Glyphs, preset lists save slots, and preset file editor UIs. Developer should only have to define a load and save function for the given script along with the UI preferences.


Norns, Grid(optional), Arc(optional), keyboard(optional)


[to be included]


Not yet available


Sorry to make an library topic for a library thats still in the works! I just wanted to share the idea early on so that I can include any ideas the community wants to throw my way.

This library is in response to this git issue. Which i think is a feature many scripts could use.


Stoked about this! I’ve been trying to jam my current script into the params system in order to use that for presets but it doesn’t scale up to sequences well.


i was just considering a data parameter type, allowing similar functionality (i think.) this would be very similar to file (maybe inheriting) with methods for attaching to an arbitrary data table.


I think that would make this util even simpler, then I would only have to handle loading and unloading the entire set of parameters and the simple UI. Im still trying to wrap my head around the other possible uses of the new type, and how the user might interface with it.

yeah, file is how I’ve been managing not flooding the params in less_concepts with a shit ton of entries – lil’ wiggly implementation which works tho. then I have a “set” param that’s just a trigger with a “load” and “save” option. 100 full sets can be saved, loaded and swapped.


yeah that’s what i mean, but i think all that stuff can be pretty easily abstracted with a deep-print function. i’ll PR it.


This is pretty similar to what I was thinking, except i was going to have the user just define what gets loaded and saved to the file after including the utility. Then when the glyph, slot, etc… UIs are called they save/load the listed objects to/from file. That way i can separate the io from the UI because UI is going to be dependent on situation and available hardware.