I thought I understood giving each abstraction a unique name, [Abst 1], [Abst 2], etc. would allow differences in each abstraction to be saved, but that seems to just load the last setting saved on the abstraction into all the abstractions when they reload. Does each uniquely named abstraction have to save it's settings externally in the parent patch? Is it easier to just use Sub-patches?

I've tried what I feel like all the relevant resources from the forums, including Whale-av's ShowMeDollars.pd file, which was really helpful, yet I seem to be no further in understanding what I need to do. There was a Maelstrom savestate patch linked to the Heurleur forums, but that seems to have disappeared.

Apologies, I know this comes up a lot, but still finding it hard to crack this. Any help/tips would be greatly appreciated, I've attached the small patch I'm working on (made in Purr data if there are any problems opening it). StepSequencer.zip

@RT-Chris Each abstraction will be identical, only the creation argument will be different. You can, anyhow, save data for each instance of the abstraction within the main patch, using [savestate] inside the abstraction.

@ingox Sorry, think I spoke too soon...Got it working momentarily inside an abstraction, but not when I tried to have multiple instances of the abstraction a parent patch, Does the savestate need to be in the main patch or the abstraction?

@RT-Chris See this example: savestate_demo.zip

@ingox Brilliant, thank so much!

@RT-Chris I could probably add that [savestate] only gives the possibility to save data from abstractions inside the main patch. But it doesn't provide the infrastructure to store more complex data, only a list.

To store more complex settings, for example different kind of types, especially lists of arbitrary length, [text] can be used in combination with [text tolist] and [text fromlist]. You can for example store each data point in one line of the [text] and when saving write the list from [text tolist] into [savestate]. It is a bit tricky, as each data point would have to have a fixed line number, but [text] only writes to existing lines or the end. So it would have to be filled with empty lines, i.e. lines containing 0, on load. After that you can write data to it and save and restore it with [savestate].

That's really helpful, thank you. I managed to merge a few lists, but I can see how as a parent patch grows with many abstractions this might get confusing. Looking into text now (for microtonal tuning), but hopefully that will help.

@RT-Chris I made these.zip a while ago using [text] to store values or lists.......I can't remember how thoroughly tested they were but they might be useful..... and anyway can be changed to meet your requirements. They don't need to know in advance the quantity of stored parameters.
David,
PS... I just noticed that they were designed for the data to be written out to and recalled from a text file...... so the store is cleared at loadbang and you would need to disconnect the [clear( message from the loadbang for data to be saved in the patch. They don't use [savestate].

@RT-Chris There is a simpler method than the one i proposed above. It is by @weightless and you can see it here: https://forum.pdpatchrepo.info/topic/12066/store-state-patch-less-state-saving-method-for-abstractions.

Here is another example of this idea: savestate_demo2.zip. Instead of [v] you can also use everything that has a send or [text] with [text tolist] or complete [array]s.

The beauty of this is that you can almost always keep the state saving stuff out of your patch completely besides that one subpatch.

Also i now see that what i wrote above is actually wrong. [savestate] can keep several lists, not just one.