I'm using [savestate] to save the state of a toggle in an abstraction. If that abstraction is in the main patch, it works properly. If that abstraction is imbedded within another abstraction, the state isn't saved and restored properly. This seems like a bug to me. Is there a way to save the state of a toggle that is in an abstraction inside of another abstraction?

I've attached a zip with three files that demonstrate the problem. test_save_toggle.pd is the main patch. It has two instances of the test_save_toggle2.pd abstraction. If you set the toggle in one of those and save the patch, the state of the toggle is saved correctly. The main patch also has two instances of the test_save_toggle3.pd abstraction which only contains an instance of test_save_toggle2.pd. If you set the toggle in one of those, the state of the toggle is not save correctly.

test_save_toggle.zip

Have you tried enabling "Init" in the toggle's parameters? Right-click on it and select properties. In the window that opens, under "Parameters", click the menu and select "Init". Probably you're aware of that and it might not work with abstractions though.

@alexandros Yes, I tried enabling Init. It did not work.

@jamcultur I think this might be intended behavior? [savestate] does its thing when the parent patch receives a save, in the case of an abstraction within an abstraction the parent patch is the abstraction that contains it, the patch is the grandparent? Docs don't clear this up and nothing on the github, there is a feature request for adding a depth argument to [savestate], but I did not read it to see if it is meant as a "fix" or extend how [savestate] works. But it seems like if this is how it always worked, this thread would be at least an annual event and it would be spelled out in the docs, so maybe a new bug?

In this case I would change how I structure my patch and abstractions to avoid having [savestate] in nested abstractions, anything else will probably result in slowly implementing your own adhoc state saving abstraction. One of the old state saving abstractions from before the days of [savestate] might work, but I remember them as not being much fun to use.

if this is the case maybe you could do a work around by sending dirty message to the middle patch, similar to how I did there:
https://forum.pdpatchrepo.info/topic/15732/how-to-save-restore-multiple-0-array-abstractions-in-a-patch/4 maybe with metro instead of ping, this way you get asked to save before closing.

[namecanvas $0-parent]

[loadbang]
|
[1(
|
[metro 20000|
|
[dirty 1 (
|
[s $0- parent]

@lacuna iemguts could make that a bit cleaner.

[receivecanvas 1]
|
[route menusave]
|
[dirty 1(
|
[sendcanvas]

And this lets us automate further by replacing [dirty 1( with [menusave( to get things so they don't require user input and everything just works. The catch would be this won't work if you have more than one instance of the middle abstraction since saving will reload all other instances and make them have identical state to the one that was saved. Or am I missing something?

@oid said:

this won't work if you have more than one instance of the middle abstraction

I knew I was missing sth.

Can we do

[savestate]
/
[route menusave]
|
[menusave(
|
[sendcanvas]

using the right outlet bang of [savestate] in the middlepatch, then [savestate] in the child as intended.

I agree with @alexandros init state should work, but in an abstraction it doesn't.

@lacuna This has the same issue, doesn't it? as soon as menusave is sent to a canvas that canvas is saved, all instances of the abstraction reload? Also, [savestate] does not like being abused this way (at least in 56.1), segfaults pd if you have more than one instance; guessing [savestate] still has the canvas id of the old abstractions from before they got reloaded by the first save and then attempts to access that no longer accessible memory? or something, but maybe it works in what ever version of pd you use and has some magic I can't see? [receivecanvas 1] seems to work safely and reliably, but we still have the reload issue.