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.

@jamcultur My best guess....
[savestate] in the main patch (as that works correctly) and global (not $0) messages to/from the [toggle] in the 2nd level abstraction.
Might need a small delay to restore the [toggle] correctly on recreation as the creation order might perturb the restore.
David.

@jamcultur said:

If that abstraction is imbedded within another abstraction, the state isn't saved and restored properly. This seems like a bug to me.

Whether it's a bug or not, I don't know, but it certainly is a data structure design problem, and I don't think it has an easy solution without radically redesigning the pd patch file structure.

When you use an abstraction in the top level of a patch, and that abstraction contains a [savestate], then the saved file includes two instructions for that abstraction, for instance:

#X obj 568 309 fader~ helpSrcA;
#A saved helpSrcA -18.5355 0 helpMain 0;

"#X obj" is an instruction to load the "fader~" abstraction from disk. "#A saved" contains the list that will be sent to [savestate] for initialization.

The scenario here, then, is that "fader~" loads an inner-level abstraction from disk, and this inner-level abstraction itself has a [savestate]. So somewhere there needs to be a unique "saved" instruction that may be different the default "saved" message in the abstraction file.

You can't save a "different from the abstraction file" saved-list in the abstraction file itself, for obvious reasons.

If you assume (as this thread seems to assume) that every [savestate] all the way down the chain should put a "saved" line into the top level file, how do you find the target for each of these "saved" lines?

If my "xyz" abstraction contains 4 references to "abc.pd" and "abc.pd" has a [savestate], then (per the assumption) there should be 1 "saved" line for xyz (let's label it s1) and 4 of them for abc (s2 - s5). S1's target is easy, but for s2-s5, you have 4 data lists and 4 targets. How to match them up? A naive solution might be to go by file order, but saving a pd patch can sometimes change the order in which objects are written out. If you modify the xyz abstraction in this way, this will not automatically reorder the saved lines in the top level file -- after that point, then, when you load your top level file, you will find the wrong data associated with the inner-level abstraction instances.

If Miller Puckette were to change the file structure so that each object has an explicit ID to which "saved" can refer, this still wouldn't solve the problem because, upon saving "xyz.pd," there is no way to seek out every pd patch that depends on xyz and redo the "saved" IDs.

It could perhaps be solved if pd copied all of the objects from abstractions into the top level file when saving, but then, if you fix a bug in an abstraction, the top level file won't pick up the change.

I think Puckette looked the complexity of this problem, and decided that the best solution was to limit [savestate] to one level of abstraction.

Intuitively, you would think "of course this should work," but when you really look at how to implement it, it's very difficult or maybe even impossible.

hjh

... whereby, a reliable solution would be that an abstraction using another abstraction needs to initialize the sub-abstraction by sending messages to it. That is:

• Main patch loads abstraction xyz
  • xyz loads abstraction abc
    • abc initializes itself by [savestate] using the defaults saved in xyz.pd
  • xyz gets data from [savestate]
    • xyz, as part of its init, sends messages to the [abc] instance to override the earlier init

Then xyz.pd is responsible for sending the right data to the right instances, avoiding ambiguity.

hjh

@ddw_music This is basically what I ended up doing. It's clunky, but it works. It looks like the feature request on github that @oid mentioned would fix the problem in a much cleaner way.

you would save it in the top parent patch and send it in when it loads probably.

@jamcultur said:

It looks like the feature request on github that @oid mentioned would fix the problem in a much cleaner way.

I would not be too optimistic about that feature request -- its current state seems to be: OP: "hey, this would be nice"; dev: "here are some reasons why this won't work"; OP: "oh come on, it would be nice"; dev: "here's another couple reasons why it won't work" ... which is kind of the same form as the thread here.

Well, the github issue ends with "let me try it in an external" but my prediction is that this effort will quickly run into trouble. It's not an easy problem.

hjh