An optional feature that when enabled would capture a copy of the current buffer (or any modified buffers) each time a run happens. The copies would be stored in a default or user specified location, named and ordered in a clear manner like buffer-<N>-<timestamp>-run-<M> for example.
This feature alone would be useful for having some basic revision control during coding sessions and being able to roll back to prior states of the code. Another use would be having full ‘transcripts’ of live coding sessions - allowing one to see the progression of changes from starting script to end as well as being able to recreate key moments of the session for further listening or exploration.
Naturally, having some UI support for viewing revision lists and loading revisions would be huge for usability but the saving support alone could be useful for many. Technical users should be able to achieve a similar system by wrapping a little supporting code around sonic-pi-tool
I think that everything you do is already recorded in a git repository in the .sonic-pi/default folder
This contains the latest versions of the 10 buffers, and the cached samples folder, but if you try
ls -al in the default folder you will see something like
drwxr-xr-x 15 rbn staff 480 26 May 2017 .
drwxr-xr-x 4 rbn staff 128 8 Aug 2016 ..
-rw-r--r--@ 1 rbn staff 10244 14 Oct 22:51 .DS_Store
drwxr-xr-x 11 rbn staff 352 13 Nov 17:36 .git
drwxr-xr-x 39 rbn staff 1248 9 Jun 15:32 cached_samples
-rw-r--r--@ 1 rbn staff 2295 10 Nov 15:55 workspace_eight.spi
-rw-r--r-- 1 rbn staff 2494 10 Nov 15:55 workspace_five.spi
-rw-r--r-- 1 rbn staff 8203 10 Nov 15:55 workspace_four.spi
-rw-r--r-- 1 rbn staff 8597 10 Nov 15:55 workspace_nine.spi
-rw-r--r-- 1 rbn staff 1263 10 Nov 15:55 workspace_one.spi
-rw-r--r-- 1 rbn staff 8273 10 Nov 15:55 workspace_seven.spi
-rw-r--r-- 1 rbn staff 1287 10 Nov 15:55 workspace_six.spi
-rw-r--r-- 1 rbn staff 50 10 Nov 15:55 workspace_three.spi
-rw-r--r-- 1 rbn staff 2202 12 Nov 16:41 workspace_two.spi
-rw-r--r-- 1 rbn staff 5719 10 Nov 15:55 workspace_zero.spi
and if you try git log
you will find that it contains a complete record of all the changes made.
eg
Robins-MacBook-Pro-2:default rbn$ git log
commit ea861dd8279707a8a87fa5385c4d7b56671426af (HEAD -> master)
Author: Sonic Pi Autosave <autosave@sonic-pi.net>
Date: Tue Nov 12 16:41:36 2019 +0000
v3.2.0-dev-740c7 -- 9a39d850-9f4e-43dc-97a2-90733463404c -- :~: Autosave Workspace workspace_two.spi
commit a4781d744d79bf74f6e98225f8d7bcf02a182923
Author: Sonic Pi Autosave <autosave@sonic-pi.net>
Date: Tue Nov 12 16:41:27 2019 +0000
v3.2.0-dev-740c7 -- 9a39d850-9f4e-43dc-97a2-90733463404c -- :~: Autosave Workspace workspace_two.spi
commit fdd58e24138f19644a84d13991ee57f55bfe1db6
Author: Sonic Pi Autosave <autosave@sonic-pi.net>
Date: Tue Nov 12 16:41:15 2019 +0000
v3.2.0-dev-740c7 -- 9a39d850-9f4e-43dc-97a2-90733463404c -- :~: Autosave Workspace workspace_two.spi
commit 44816e0c407276ec38ad5bb480871f1aeec559d4
Author: Sonic Pi Autosave <autosave@sonic-pi.net>
:
(You can press enter to see further entries, or q to exit)
Of course, to use it easily you would have to develop this, but I have on occasion retrieved stuff from a buffer that I have accidentally deleted, using standard git commands.
That’s great! I can’t tell at a glance, but it looks like these might be correlated with run events (based on my log and recent activity). I wonder if auto-saves happen any other time; if so, tagging the commits could help differentiate the source of the save operation.
One of my early experiments as a Sonic Pi developer was exploring the implementation of a Sonic Pi ‘History browser’. This basically displayed a simplified graph UI allowing folks to navigate through the revision (commit) history and easily browse particular versions, optionally tag them with custom labels, and reload and/or branch off them for further adaptation.
Given that I had done hardly any C++/Qt development before at the time, (and I’m still not highly experienced at it these days either) what I managed to build was hugely inefficient and took far too long to load things etc - so I basically gave up on that idea.
I would still definitely be interested in building something like this, but would either need help to find and/or build a suitable approach, or time to be able to learn more and find out one for myself
Hey all, when loading a script into sonicpi (by running a command) is it possible to say which workspace file the script is to be loaded into, instead of current?
Just tinkering with an idea, trying to understand current technical challenges & limitations
I see run_file runs the code but doesn’t load/replace, whereas load_buffer appears to work with the current ‘workspace’
Also, re buffers and workspaces, I tried the record fx with a named buffer (simple play note, no loop) but can’t seem to play or use the buffer with the recording. How do you use the buffered_recordings?! And can the workspace_buffers be referenced by the record buffer command, or are they different buffer types?
