Autosave options?
Are there any autosave options to use in pure data?
I recently found a bug where the program in a certain condition crashes. I'm now aware of what's that condition and I'm pretty able to avoid that while editing a patch, but before that I ended up losing a lots of changes because of the bug and I had to redo everything back from the last save, costing me a lot of time.
If another issue would appear it would be very frustrating.
So how can I automatically save every 2-3 minutes for example?
If you don't mind using externals, you can use [iemguts/canvasname] to redefine the path that the patch will save to.
@60htz This saves the patch to a backup location and back to the current working location. For some bug or reason the title bar will not be updated after the second operation (at least on my linux/vanilla), so the redundant menusave will just take care of that.
For making it an abstraction, i think paths and filenames would have to be provided as creation arguments. Also there is [namecanvas], which is vanilla but i guess won't be of much use here...
@60htz Here you go.....
This will open a patch, and save it to the desired location every minute. You could easily add an argument for "every".
When started it opens the patch.
It then saves both the patch and the backup.
File names and paths set as arguments.
saveme.zip
Extended and Vanilla.
David.
When time allows it could maybe be done through $focused_window....... but that might risk saving the whole desktop somewhere?!
@LiamG
Yes, I tried canvasname at start, but it "query and modify the name of a canvas" , wich is different than getting the main patch filename and it only works for abstractions and subpatches. I really think that it's not possible to get the patch filename until [canvasinfo] in pd-l2ork and purr data I think.
@whale-av
Thanks, it looks to be a working way , but I am still wondering if making a copy of the original patch somewhere could be done WIthout saving the state of the original patch... like autosave features in many softwares 
@60htz I will look into it. The problem, as you mentioned above, is that when it is saved the link is updated to the newly saved backup, and that is the file that is then open..... so you are working with the backup.
Then the original needs to be reopened, but if it is not saved first then the recent (1 minute) work is lost.... it is only in the backup.
It might be possible to flip-flop between the two.... maybe..... but that is not the same thing.
Why would you not want to save the working patch?
David.
Here is an attempt that doesn't save the original patch by selecting everything, opening a new file, pasting the contents, saving and closing the backup. The backup file is closed at first to prevent a crash in case it is already open. This leaves all objects selected, which is ugly. It could be undone by sending a mouse message, but i think it is an ugly way over all.
i think saving the original patch would be the better way.
@whale-av
I make workshops with students and some of them often make mistakes and lost they work and motivation... I'd like to found a way to provide them with a reliable auto-backup option if possible.
@ingox
Clever way to do it! It works and there is no "break" in the time process...
Since extended have no "menunew", I replaced the message with:
[;
pd filename backup.pd /Users/raphael/Desktop;
#N canvas;
#X pop 1;
(
Now I am searching a way to disable selection but I don't understand how [mouse( message works to simulate a mouseclick.
Next, I need to test this in an "everyday patching situation" to check if it's reliable!
@60htz If saving the original file is still an option for you, you may also want to reconsider the proposal above which does the saving completely in the background without opening or closing any window. So it won't alter the mode, or disrupt the workflow in any way, should even be working in the background if the patch is playing. (in theory that is, havn't tested it)
i added a close message to prevent a crash if the backup is open. It can be easily turned into an abstraction the way @whale-av did it, but i don't have the time right now to do it.
Could also be expanded to save different versions over time and so on...
Also maybe of interest that ./ works on linux and probably osx for the current directory. This could serve as a default in an abstraction, but i don't know if it works on windows.
Here is the updated version with the closing message for the backup: savethis.pd
@60htz here is a collection of many pd messages, including mouse: https://forum.pdpatchrepo.info/topic/10813/collection-of-pd-internal-messages-dynamic-patching
The thing is that mouse only works on a visible window, so you would have to send [vis 1( to the window to make sure it is working and thus possibly disrupting the workflow. i don't see a clean solution for this...
Edit: Or maybe it doesn't matter, if the window is in the background... i don't know, just think the attempt is messy 
@60htz I think you will need a "mouseup" plugin to release the selection........ we were working on it earlier...... mouseup-plugin.tcl
Does that work...... ? send a bang to mouseup........
bang
|
; s mouseup(
I am most of the way to saving numbered backups....... with a step back function.
Have to stop now though....... so later hopefully.
@ingox
Nice, I will dig into [vis 1( solution!
I am using OSX but I will try on windows too.
@whale-av
Thanks, I will try also this tcl plugin as soon as I can and would be happy to test the step back function.
After all that, still need to get the main patch's filename to feed the [send] object with the actual patch' name... wich surely be different than savethis.pd
For the mouse event, I found that [mouse( then [mouseup( message did the trick perfectly:
[mouse 0 0 1 0, mouseup 0 0 1 0(
Now trying with a metro every minute and it breaks the patching experience because of current object deselection/patchcord cancellation during the process of course... grrr almost ok! 
@60htz yes and it will always throw you into edit mode, even when you are in play mode (?) to test the patch. unfortunately there is no way of telling in what mode you are currently in as far as i know, so i think this whole attempt is not leading anywhere. i still favor the saving in the background solution, but that's just me
@60htz [s pd-patch.pd editmode 0(........?
@60htz Maybe...... autosave.zip
Please test to destruction.
Once started the user is always working in the latest saved backup (for 60 seconds/backup file)...... until deciding finally to write over the original patch (if desired).
Pressing "Start" again will force another (un-programmed) backup.
Having saved over the original the job is finished.
The user will need to restart [saveme_master] to work again with the patch if autosave is required again.
Endless "undo"..... and backups still stored until purposeful deletion.
However, starting the patch again will write over the old backups, unless a new folder is specified.
If the user goes back to a saved backup they can start working again from there. The sequence of backups will start again after all of the previous backups.
That can be forced by pressing start again........ or will not happen if the user moves forwards to the last backup before the timer sets another backup.
The user can always move to any backup and start working again.
Edit-mode is maintained (on or off), but when stepping forward and back edit-mode is off, and all values stored in objects are lost (unless "init" properties are set).
It would be trivial to set edit-mode on when stepping.
David.
Thanks @whale-av, it looks to work. But I notices that the save process always break the patching experience like writing in a new object while saving exit the texte fill process etc... don't know if there is a way to avoid this... and the original still get saved along with the backup.
I may have find a solution for changing the patch silently, using sys_gui and send pd command in tcl. One of the key might be using the ::pd_menucommands::set_filenewdir command and change the working directory temporally, save the patch, then revert the path back?
But don't know how it works since I tried with ggee/getdir and get errors:
[ggee/getdir]
|
[$1/backup(
|
::pd_menucommands::set_filenewdir $1
|
[hcs/sys_gui]
returns:
(Tcl) UNHANDLED ERROR: bad window path name "/Users/raphael/Desktop/PureData_MEANDRE_2.8_MAC/MEANDRE/extra"
while executing
"wm attributes $mytoplevel -titlepath"
(procedure "::pd_menucommands::set_filenewdir" line 5)
invoked from within
"::pd_menucommands::set_filenewdir /Users/raphael/Desktop/PureData_MEANDRE_2.8_MAC/MEANDRE/extra "
("uplevel" body line 2)
invoked from within
"uplevel #0 $cmds_from_pd"
@60htz Strange...... the original should not be saved until "happy" is banged.
Yes, the working patch is interrupted, although data is preserved if "init" parameters are set......
I think any save at all will interrupt........ the patch is in working memory.... and re-loaded when saved.
Yes, tcl helps........ and gives this solution.
The contents of the patch are saved to sequential backups, without saving the patch itself (as you required)..... The working patch remains in it's unsaved temporary state.
You need [sys_gui] therefore for vanilla (included in the zip for windows only)...... and will need a workaround for [getdir] as well, maybe specifying the working directory in the arguments.
It is a "sort of" macro.... and a shame it is so simple compared to the work I put into the last attempt!
It relies on the fact that "new" creates "Untitled-x.Pd" files with an incremented index.
Hopefully perfect.....
User returned to editmode 1 (I will look for a way to know which mode they were in.. and return to that state)
auto_save-4.zip
There might be a way to do it without sys_gui...... needs looking at as well..... but I doubt that there is!
David.
@whale-av @60htz
There is a method that doesn't interrupt the workflow, as shown above...
Edit:
Also, when saving another patch than itself, the redundant save isn't even needed. Undo still works, at least with strg+z/ctrl+z.
Oops! Looks like something went wrong!