I've just started using the [savestate] object for the first time and I've managed to modify my patch to make use of it, but I have a question. It appears that the user has to remember to do a save (Ctrl-s) in the main patch for the state in an abstraction to get saved properly. I assume that's the way it's supposed to work, but I'd like it to happen automatically, or at least prompt the user to save the patch when it's closed. It's just too easy to forget to do a save, and if you do forget, the state doesn't get saved properly. I thought of sending a "dirty 1" message to the canvas every time a saved parameter is modified. Is that the best way to do this, or is there a better way?

@dfkettle There could be a better way, but you can send a message to Pd as the patch is opened that will provoke a "close this window?" message every time you close the patch.
The downside is that it will happen for other patches and for the Pd console until you restart Pd.
It puts Pd in Performance Mode........ "Perf Mode" which was a menu option in Pd extended..... but the message works in Vanilla.
I find it very useful for patches running live for a show.
[;
pd perf 0( turns it off.
David.

@whale-av I don't want the prompt to appear every time, I just want it to appear if some changes were made to the parameters being saved by [savestate]. My idea seems to work. When I close the main patch, this window appears, but only if something was changed.

Is "perf 1" another undocumented message? I don't remember ever seeing any mention of it.

@dfkettle Probably undocumented..... there are loads.
My favourite finds are probably the ping message from Pd that you have seen....... and that you can send [click( or [close( into [text define] to open and close the text window programatically........ but those messages have been added to the help file for [text] now.
Trawling through the code is often the only way to find these things.
David.

@dfkettle This works but is not perfect.
saveas.pd

Edit: Guess I did not really read your post very well. Should wait until after coffee to post.

@oid That's essentially what I'm doing, except that I don't have [iemguts/receivecanvas], [route menusave], [1(, and [spigot]. They don't seem to be necessary. So all I have is this, plus the [savestate] logic of course.

Thanks!

@dfkettle The spigot and related logic means it does not send a [dirty 1( for every change, just when needed, more efficient. In your way if you slide one of those sliders from top to bottom you send [dirty 1( 127 times, which could cause issues and lag things if the processor is nearing its limits. So first change closes the spigot and no more messages sent until you open the save panel, then the spigot is opened back up until the next message goes through and closes it/sends [dirty 1(.

There does not really seem to be a good way to do this, you can not use it in an abstraction since it will set the abstraction to dirty and prompt you to save the abstraction so you have to design your abstractions around utilizing this which is sort of awkward, like the old days when there was no single way to save state and using other peoples abstractions could end up with a mix of different methods plus ones with no consideration taken for saving state. Perhaps a feature request is in order.

@dfkettle Updated the above, changing the [route] to [route menusave setbounds] allows it to catch 'save as' as well. Also catches a few other things like opening a subpatch or opening any window (help/prefs/etc) from the patch's window, but being a little redundant is probably better than not catching the "save as."

Suppose we can also do this and just consider any mouse click to be an edit even if it did not change anything. Uses far fewer wires and decreases headaches in dealing with abstractions, but could cause headaches in some patches.
save1.pd

@dfkettle This machinery should set the patch to dirty only once at the first value change and again after the first change after saving the patch and so on: dirtydemo.zip.

@ingox @oid Thanks. For the patch I'm working on (a MIDI sequencer), it probably isn't necessary. It's unlikely that anyone would want to modify these parameters while the patching is running, they're things like MIDI channel, the name of the sequence file to load, etc. They'd be set once when the patch is first opened, but not changed while the sequence is running. And there's no audio processing anyway, it just sends out MIDI data. However, I'll keep this in mind for the future.