Pd 0.49.1 has a new object [savestate] for saving lists of parameters to the parent patch so that different instances of an abstraction are saved with different parameters. The help file for it shows a method of creating/unpacking the list which I think is a bit awkward for abstractions with lots of parameters as it requires a lot of patching and is dependant on the order of packing/unpacking.
I have adapted the method used for saving presets to a text file to do the state saving in a very similar fashion here. Store.state-help.pd explains its workings as well as I could, hope it's clear enough.

store.state1.0.zip

In the future I'd like to merge this method and the text file preset saving to work alongside (where the presets are just multiple states, basically), but for most purposes I think the state saving is more useful and immediate than presets. At least for me, anyway.

This new object opens up interesting possibilities so any feedback or alternative methods are welcome.

Am I missing something? How is everybody using this object?

I can imagine some problems using the init option for sliders/toggles/radio etc and savestate at the same time, since those init values would override the savestate. For loadbang, Miller's trick is probably enough, but for init I wouldn't know. Probably best not to use it at all?

store.state1.1.zip

I have added some more abstractions for saving arrays and text which are in the parent patch, this should cover pretty much everything I think.

store.state1.2.zip

At that point, I think it's more efficient if the presets are stored in text files so that they can be shared by all instances of the abstraction.

@weightless How would this work in the context of [savestate] - the text files would be loaded into each instance of the abstraction individually, or as one global preset load? (sorry I'm probably over-thinking it here!)

I had it in my mind as a global patch state, a bit like SSSAD which I used a lot in the past but I guess this how [savestate] is working anyway. A later development to the initial sssad work brought an abstraction (can't remember the author) called [presetstore] which allowed you to save multiple global states in one patch. I guess what I'm trying to avoid is saving multiple versions of one patch, as it seems inefficient to me.

@ingox said:

[savestate] may allow to include the [text] to store the presets individually inside the abstraction, which could be beneficiary.

@ingox that is a good point!

cheers all

How would this work in the context of [savestate] - the text files would be loaded into each instance of the abstraction individually, or as one global preset load?

They would be loaded only in the instance of the abstraction on which you save the presets. Think of it this way: the abstraction contains a [text] object, and you save its state (ie, the text it contains, whether it's a set of presets or a poem) which can be different for each instance of the abstraction. I can't see any advantages with this approach, but it may work for you.

So it’s the multiple abstraction states saved as presets in the parent patch, that I can I can recall at any time, either by a little gui, or messages, that would be my preference.

I can’t see how I would achieve that on a global [savestate] level, unless I can poll all the [savestate]s inside the abstractions into a global text object and save that into a parent based save [savestate] maybe

I can’t see how I would achieve that on a global [savestate] level, unless I can poll all the [savestate]s inside the abstractions into a global text object and save that into a parent based save [savestate] maybe

You can simply use [text define -k] and the contents will be saved together with the main patch, which is the equivalent function to what [savestate] does for abstractions.