Hi everybody,

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.

@weightless i don't get it. The whole point of having an object like [savestate] is that you don't have to create abstractions with individual arguments for state saving...

@solipp Maybe I'm missing something but as far as I can see, [savestate] just saves a bunch of lists to the parent patch and links those lists to the instance that sent them, so that when you open the parent patch again each instance of the abstraction gets back its respective lists. But there is no built-in way to associate each list to the corresponding parameter, and whenever you open the parent patch each instance of [savestate] that you have in there receives all lists relative to that abstraction. How do you parse those saved lists? I think you have to either pack/unpack your parameters into a single list like in the help file, with each element of the list being a single parameter (which doesn't seem practical to me, especially if you want to save variable length arrays and text), or you can create one list for each parameter, but in that case you need to attach some sort of identifier to each list so that you know how to parse them. Something like this:
Which is exactly what I did, except that by making abstractions for this mechanism you don't have to copy/paste/rename it every time you add a new parameter to your abstraction.

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

@solipp at least you need to route the values somehow to and from [savestate]? on the other hand it is possible to save [array] and [text] with the -k flag and toggles/sliders/Radio/numbers2 with init. but the difference to init and -k seems (from the doc): "[savestate] output comes before [loadbang], this mechanism was suggested by Miller in the Pd list and allows to set default values for the controls which will be used whenever there is no state saving in the parent patch. If you open this file (store.state.pd) it'll load with these values."
edit: wrote my answers before i saw the one from @weightless, so it is kind of redundant...

@Jona The main difference with the flags is that if you have an abstraction with the object [array define -k ..], the same content of the array is saved for all instances of the abstraction, whereas [savestate] allows you to save different values for each instance.

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?

@weightless sorry, i got it wrong. Of course it's meant to be copied into the abstraction... I should study the helpfiles more carefully before i post..

@solipp No worries, I can see it's not very intuitive. Given the object's very limited documentation this is the most modular solution I can think of. I would be very interested to see some alternative uses.

Doing some more experimenting with the savestate object to save parameters which are not in an abstraction but in the parent patch, it seems that there is some odd behaviour in that when the patch is loaded and savestate receives the lists, they are available inside the abstraction but cannot be sent out to the parent patch directly via outlets, I wonder why that is. This is shown on the right hand side of store.state-help.pd.

store.state1.1.zip

@weightless interesting... it seems that initbang sneaked into pd-vanilla, at least you could use savestate in the same way: savestate_as_initbang.zip

@solipp Very nice, thanks!

@weightless that's why you don't get a result from the outlet. Like initbang, savestate sends the list "before" the abstraction is created/connected in the parent patch.

@solipp Oh I see, yes that makes sense now. In fact I think it's more useful this way precisely because it works like initbang, and if you need to send stuff to the parent patch you can always do it with loadbang.

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

@weightless you mentioned saving multiple states in some kind of preset system, how would you go about doing this using the [savestate] method here?

@boonier I haven't had time to think about it, but in fact my feeling is that it wouldn't have any advantages at all. With presets you have to chose when to save a new one, compared to saving the "state" in which the abstraction was when you saved and closed the patch. 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.

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

@weightless said:

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

@boonier said:

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.

Yes I agree that presets only local to a single instance of an abstraction is a bit limiting.

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

@boonier said:

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.

thank you @weightless, this patch is awensome and saved my life.