@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.