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?

Well, I've been browsing the source and it seems like there is some groundwork for saving the state when Pd closes. It's even in the menu for the test version I had been playing with, But I don't know if it works properly or why it hasn't been implemented. Until then, I'd say just remember to save your program all the time with the keyboard shortcut.

http://forum.pdpatchrepo.info/topic/9684/how-to-dynamically-save-a-pd-patch-to-a-specific-location

maybe using a counter and metro object you could automate saving new versions.

you might also want to look at bb_uname from here bitsynthesis.com/pd/
to "Generate unique file names based on the date/time. "

also [ggee/getdir]

@Shindeibrauns Metro (time you wish) bangs the message.......

[savetofile newpatch.pd home(or full path)/my/directory(
|
[send pd-mypatch.pd]

Set two filenames alternating if you might want go back.....
David.

Thanks a lot, this is actually pretty useful!

Hi everyone,

I'd like to make an autosave function, so basically the patch would save itself every minute to a special path and file.

The problem is that using pd-message like:

[savetofile name.pd path/to/somewhere( (== menusave)
ı
[send pd]

It changes the name of my main patch to the new name and set his new curent location, but I would like to make a copy somewhere else and keep the current path for the current pd project. I tried also the message:

[saveto name.pd path/to/somewhere(
ı
[send pd]

But pd-extened close or pd vanilla 0.47-1 complain:
Bad arguments for message 'saveto' to object 'canvas'

Any hint?
Thanks!

Thank you @whale-av,

But when saveme.pd should be the actual patch's filename as variable, I think it's difficult to catch it since (correct me if I am wrong), [canvasinfo] is only available in purr data and not in extended or vanilla as an external library...

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

savethis.pd

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

savethis.pd

@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

@whale-av

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