saving/loading + uploading/downloading

[schollz]

hi @tehn, thanks for this wonderful dynamic and deep script. i feel like i keep finding interesting patterns as i randomize the two loops. i was interested in saving+loading from the menu so i made my own branch: https://github.com/schollz/awake. i think this differs from the regular save in that it provides naming in way that will allow easy sharing, as i think i'd like to also add a possibility to share saves, via another menu to upload/download.

i'd like to know if either of these things is something within the realm of your script and you'd like a pr, or if not, i'm totally happy keeping it as a fork.

[tehn]

i could see save/load of sequences from the menu making sense--- what's the UI proposition? how would upload/download work? that an intriguing proposition, though possibly riddled with management quirks :)

…

On Sat, Dec 5, 2020 at 10:30 AM Zack ***@***.***> wrote: hi @tehn <https://github.com/tehn>, thanks for this wonderful dynamic and deep script. i feel like i keep finding interesting patterns as i randomize the two loops. i was interested in saving+loading from the menu so i made my own branch: https://github.com/schollz/awake i think i'd like to also add a possibility to share saves, via another menu to upload/download. i'd like to know if either of these things is something within the realm of your script and you'd like a pr, or if not, i'm totally happy keeping it as a fork. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB4I4CX5FANXE4IJGEGXETSTJGYRANCNFSM4UOTYA7Q> .

[schollz]

my ui proposition is to have a menu for save/load for adding specific filenames to saves. below, i'll explain why this is important if uploading/downloading is an option.

upload/download works by uploading all the needed files to a public place (right now a server i have on digital ocean, but need not be my server). every file is signed by a rsa keypair that is initialized by another script (norns.online). everything is public, but the keypair ensures that only the person registered as "bob" can edit/upload/delete stuff as "bob". also, theoretically, it doesn't require trusting the public server as every file can be checked locally using a public key that someone gives you.

the tricky part about upload+download is how to avoid naming collisions when acquiring other people's stuff. for barcodes+oooooo i followed dan's path in cheat codes to essentially bypass PSET and use a naming directory. the naming directory <pathtodata>/names stores the names of stuff and then a folder for each dataset is made with parameters, tables, sounds for that save. this is really easy then, when you import someone else's data it can prefix their name to the name of the dataset and add the name into the naming directory. this is what i added in this pr.

but....i'm realizing now that scripts like awake only need the parameter set to save and this is well done in the PSET option. but, please correct me if this isn't the case, the PSET option seems to need to be enumerated so it would be hard to import someone else's cause the number could collide (say if you both have a awake-02.pset). so, now i'm actually thinking this is not a good pr for this, as its incompatible with the ways people have been saving/loading awake saves. would appreciate advice on this, but also i'm happy to just leave your wonderful script alone. its totally perfect the way it is. :)

[tehn]

this is a fascinating, weird idea... i like it.

my initial response is, why should this be specific to awake? ie if you're going through an identity-indexing process with norns.online, perhaps part of norns.online should be some sort of pset sharing system itself? where that script could scrub filenames/etc and then upload/download them to the right place? this way it'd be a generalized approach to any script, not just awake?

[schollz]

why should this be specific to awake? ...generalized approach to any script, not just awake?

i thought a lot about a generalized approach and i'd love more feedback if you have ideas, but the main snag is that different scripts have different saves. awake only has a pset, but a lot of scripts have gone beyond just psets. for instance, oooooo saves softcut buffers + psets + tables. cheat codes saves a dozen little tables. so the approach i've settled on is adding a little function (like the one i've added here in awake) that handles each script's different "save" type.

however, a lot of this sharing code function is redundant between the scripts. a more generalized approach i can think of at this point, which would be an improvement on this pr, is this: make a SHARE menu group available at the core level, with a UPLOAD file selector that has a user-defined callback function that can be designated to upload specific files depending on which file is selected. in something like awake, the user would select one of the psets. for something like cheat codes the user would select a file in its names directory. the script author would then designate how the selected file is interpreted to choose which files will be uploaded (for awake you'd just upload the file, for cheat codes you'd find all the files in the directory of that name and upload them). the DOWNLOAD is always generic, since the metadata dictates exactly how to position files on the norns for loading.

this is a fascinating, weird idea... i like it.

i'm glad you like it! but to be frank, i honestly don't know if this would be a useful addition for norns' users. this was really easy to make and i decided to make it after talking to dan and another music teacher about using norns in an education setting- in that case something like this might prove useful. but i've added this to barcode and oooooo five days ago, and based on the keys added to the server, there's not a lot of interest. maybe its too short of time to tell, or maybe something else doesn't click (documentation, implementation, etc.) but i'm happy to let ideas be ideas if that is the way of things.

[tehn]

apologies for the delay.

i think a generalized sharing tool for just psets makes sense. any more-complex script could simply fork the library.

i'm hesitant to accept this feature into the core codebase as it feels difficult to maintain, and the UI feels substantial. theoretically the lib could handle all of the UI if called within the script, but menu integration would only allow param-level additions... i'm not sure that's sufficient, but it could be

so, this seems like a good path:

• have the SHARE util as a lib, with its own repo and demo script, and instructions for adding to an existing script
• each script can have a copy of this lib in their lib folder, i'd be happy to accept a PR for awake with this

happy to hear further thoughts