Simple methods of state saving run into a hurdle when the atoms you want to save are embedded within an abstraction that is used multiple times. Because there is only one physical instance of the abstraction, it will only save whatever values it was given last, and the next time you open the patch you will see only these values cloned in every instance of the abstraction.
The solution is to synchronize all system values with creation arguments. These are saved in the parent patch and can be unique to every instance of the abstraction. But how do you save the creation arguments automatically? By using [textfile] to modify the parent.pd file.
The attached files demonstrate this, using a simple abstraction with three variables. In this example, the variables don't actually control anything, but you should be able to modify this patch to your own to achieve state saving in any abstraction. There are instructions inside the abstraction.pd file on how to do this.
Please also read the warning in parent.pd. This is experimental work and I don't want to damage anyone's prize patches! Also, please get back to me if you find any bugs. I haven't tried saving a really large patch yet, although I don't see why it wouldn't work.
Happy patching!
state saving.zip (EDIT: don't download this--go straight to v1.3 at the bottom)

Really cool Liam, thanks for sharing this!

Take care,
Gilberto

@LiamG Wow this is really clever. I'm a fairly new user so it's going to take me a few days to wrap my head around what you did in the abstraction (especially [pd saving]!). So far it works perfectly out of the box on 43.4-extended on OS 10.6.8. I'm going to try modifying it later this week to fit into other patches so I'll let you know how that goes.

No problem, I'm glad you find it useful! Sorry that [pd saving] is so messy. I've tried several times to clean it up, but it always seems to remain tangled. And the truth is that even I don't remember how it works exactly. (Does that happen to anyone else?)

If you want to merge it with other patches, you should focus on the [pd numberchruncher] subpatch. This is where the save list is packed and unpacked, and you should be able to incorporate your own save list with parameters that are actually useful. The rest of the patch should be able to cope with any changes you make in here. But feel free to ask questions if you get stuck.

It works! It needs to be tested but it's very promising. I still need to understand it. As Gilberto said, thanks for sharing it, Liam.

I just worked out that this whole thing is redundant because the [iemguts/canvasargs] object can edit the creation arguments. You can use this one object instead of editing the pd file as I described. What an idiot I feel like now! You have no idea how many hours it took to put that thing together.

I shouldn't have been so bitter about this, because my discovery drastically simplifies the process and improves the performance. State saving is now seamlessly integrated into the normal PD saving dialogue. Create as many abstractions as you want, change the variables, then select menu save, and all of the variables will be saved (through creation arguments).
Anyone should be able to read the patch now and incorporate it into your own work. If you were trying to make sense of the first one, you should give up right away and move on to this!
state saving_v1.2.zip

@LiamG Really cool, LiamG, thanks for sharing this!

@LiamG Yeah this is pretty much amazing!

I'm sorry for being such a novice, but I do not understand how to use this. It is apparent how to save the values in the patch itself on the canvas that appears when I call it as an abstraction, but not how to save the states of my other abstractions open in the same patch, or any of the numbers, symbols, or sliders in the patch already.

Thanks so much for your work, please help.

Hi @Matt-Stalcup, and welcome to this forum. When I first saw these abstractions I didn't think of how to implement them in a patch, and now that you asked it I also can't see how they would do that either. Maybe @LiamG can clarify this to us here, but I believe you would need to create some inlets and outlets or adapt his idea in your own work. Also note that sliders can automatically save their values in Pd (just right click on them, click properties and click in "No init", which should change to "Init").

Take care,
Gilberto

Yes, I'm happy to help here. Unfortunately, this isn't an "out of the box" kind of a patch that will allow you to save the state of any abstraction immediately. It is more like a technique that you can use to adapt your abstraction so that it will save.

The first question is, do you actually need to use abstraction saving? This technique is useful only in a situation where you want to save multiple instances of the same abstraction, each with a different set of values. If you aren't creating multiple instances, then this technique is unnecessary--you can just you the "init" setting that Gilberto mentioned, or some other technique.

If you are creating multiple instances, then you'll have to adapt your abstraction to fit this patch (or vice versa). The steps you'll need to use are something like this:

1. Identify all of the variables that you wish to save (ie. floats and symbols)
2. Go inside the "numbercruncher" subpatch. Here you will see a list coming in which is unpacked and sent to three canvas objects (float, symbol, slider) and then re-packed again. You need to update this list with your own variables. So for instance, if you want to save three floats, you can add two more f's to the [pack] and [unpack] objects, and then attach them to some new sends and receives.
3. You will notice that the list also has some other items ("flt", "sym", "slider"). These are just labels to help you read the save list. You can either update this as you go ("flt1" "flt2" "flt3", or "attack" "sustain" "decay"), or you can remove them entirely, as they don't really serve any function.

I hope this helps. If not, let me know.

Thanks for the detailed explanations, @LiamG. Also, @Matt-Stalcup may be interested in checking this discussion we once had about state saving: http://forum.pdpatchrepo.info/topic/8782/state-saving

Best,
Gilberto

Wow! thanks so much for the help to both of you. It really amazes me that learning can be free!
I've come up with a roundabout way of saving multiple abstraction states by linking them to a subpatch that saves their parameters in sliders. It's a little goofy and it requires that I make a new subpatch for each abstraction in my patch, but it already makes what I'm trying to do much much easier.

(btw I'm trying to set up something that feels like playing a buchla 200e. It's gonna take quite a while and be nothing like the buchla 200e.)

I'll def look into using that patch you made, @LiamG .
And thanks for the crucial tip, @gsagostinho.

@Matt-Stalcup We're happy to help! Finding your own solution is definitely way to go with PD. Keep on experimenting and let us know what you come up with.

If anyone is interested, I managed to simplify the patch quite a bit by using the [canvasargs] objects to load the creation arguments, instead of the large [pd creation] subpatch from the original. It does the same thing, but it's now even smaller and more elegant.

state_saving_v1.3.zip

I stumbled across this forum while searching out ways to state save in pd, and specifically with abstractions. Just wanted to especially thank @gsagostinho and @LiamG for this very helpful contribution. The adaptation of this code works great. Exactly what I was looking for. Thank you!

I've bundled this technique for saving variables in the creation argument into a package which should be very accessible and easy to use. It's called [psave] and it's available in the Context library. All you need to do is create a few objects and your abstraction will automatically save--no extra patching necessary.

There's a guide in helpfiles --> state_saving_abstractions.pd explaining how to use it. I hope someone finds it useful!