search

GameOfLife / Unit-Lib

The Unit Library is a system that provides high level abstractions on top of the SuperCollider language.
25 stars 6 forks source link

save Udefs with score ? #16

Open miguel-negrao opened 11 years ago

miguel-negrao commented 11 years ago

When a score depends on user generated Udefs it would be convenient to be able to save the Udefs with the score, to record the full state of the piece at a certain moment in time. As a piece evolves Udefs will change, so that would make it easier to go back to a previous version.There are also other resources that could be interesting to save with the score, such as customized functions to generate gui controls, scripts, etc, perhaps it could just be a general placeholder for any type of object.

woutersnoei commented 11 years ago

I suppose this could be a feature of USession. Btw, it is possible to make Udef files auto-load at score opening. They have to be in the same folder as the score file. But of course, once loaded, they won't be replaced anymore.

woutersnoei commented 11 years ago

I could imagine a re-write of the usession file format; instead of a single usession file, we could perhaps create a folder with an index file (perhaps an usession file), separate .uscore files for all UScores that are in the Session, and separate .scd files (perhaps in subfolders) for all Udefs and UMapDefs used in those scores that are not in the default library. For that we would need to allow links in the usession file format, which probably isn't that hard to do.

woutersnoei commented 11 years ago

And then of course, USession should auto-load all enclosed Udef/UMapDef files when opening the session file, regardless of them being already defined or not.

miguel-negrao commented 11 years ago

Ok, I didn't know about the udef auto-loading, that is already super useful. Yes, I guess it does make sense to save it USession since then you have your score there but also other things that you might want together with it. I wonder thought if it's easier to save just as one text file with one compile string, with all the extra items stored inside the USession or with a folder with separate files.

  1. single file: So loading this usession file would load all the udefs there and other resources, then if the user wanted to alter the udefs, it would have to copy the text of the udef to IDE window, change and re-execute the udef code (which updates the udef in the global dictionary) and then when saving the session again it would go through all the udef symbols in the session and update them to latest version in the global dictionary (that could be made optional with a flag also).
  2. directory: each saved version of a usession would require a separate directory. Editing the udefs without destroying the saved version would mean, first saving a new version which would create a new directory and save the scores and all udefs in separate files. Then open one of the udef files and edit.

Since the objective would be anyway to keep a version of session including all assets has it was at a moment in time, having it all in one string makes it more difficult to accidentally alter the udefs regarding that version. It's also easier to move one file around then a directory. Altering the udef files on disk would alter a saved version of the session, which is not what you expect of documents, if you alter a document (say in word or logic) the original is only altered once you do "save". On the other hand with a single file it might be less convenient to alter the udefs since the text has to first be copied onto a new text window, although I saw in the list that Scott is working on Document support the IDE, so that might be easy to do in the future. I don't have a strong opinion either way.