I'm been developing a way of saving a range of presets created by an abstraction as txt files, but wanted to see if there was a way to save these presets in the same absolute location as the parent where abstraction is instanced. I've been toying with retrieving the location using open/savepanel in the parent file, and calling on that for each abstraction, which works, but for future ease I was hoping to skip relying on this step and have the abstraction read the absolute saved path of the parent file its loaded into. I could also use the automatism style and just copy the folders over into each project, but would be so much neater to just rely on global abstractions.

I'm sure this can be done as savestate relies on the parent's saved location, but finding the info that comes with savestate a bit limited (I'm not using save state as I want to have multiple different saves available to whichever abstraction is used).

@RT-Chris Check out [pdcontrol] with the [dir( message.

Another way could be to organize the saving from the main patch. Especially if the contents to be saved are all in arrays or similar, the main patch can access them without even touching the abstractions.

Thanks as always @ingox , unfortunately it looks like the latest Purr Data release doesn't have the [pdcontrol] object yet for some reason...
There's no other way of retrieving it via an external I guess, might just have to wait for this to make it's way into the next bigger lork/fork

Thanks for the alternative suggestion also. I suspected it would make it a bit messier, and liked how with this way abstractions would be kind of self-contained and just work, but that might have to be the way this goes for now...

Just found [ggee/getdir], this does exactly what I want!

@RT-Chris The benefit of a centralized solution via main patch would be that all project data can be easily saved in one text file, although this can also be achieved otherwise. Anyhow, it is just a matter of personal style.

@ingox For sure, think I've been slowly trying to get things working in small increments, and not looking at the bigger picture - that's good advice about centralising the saving in the parent patch.

Still seem to be struggling to save in a absolute file format. Have managed to establish the absolute path as a symbol using [getdir], but when I pass it through [write $1< into [text define] it fails. I assumed it was to do with spacing, but I tried a spaceless directory/path and that doesn't seem to work either. Might have to go backto the drawing board with this one...

@RT-Chris This works with spaces on linux: save_file.pd

Thanks, that's really helpful to see how that works I never would have figured that out. Looks like it's converting it to a string so PD can read the format. I remember reading spaces were an issue.

@RT-Chris Here an example of how abstractions can save arrays in the directory of the main patch using [ggee/getdir] or vanilla [pdcontrol]:

save in main dir.zip

And one example how abstractions can write arrays to the same file in the directory of the main patch.

save in one file.zip

Also an abstraction that works somewhat similar to [savestate]:

filesavestate.zip

It has a limitation in that it will give an error if the file to save to does not exist. So it may be useful for preset systems with a fixed number of slots.

There is also an example system with five preset slots.

@ingox wow, thank you for all of this. Never anticipated how complicated saving might get, but once I study this a while I'm sure I can get a handle as to how it works. Is a lot of this stuff just not in tutorials / guides out there? Seems like there's a big gap once you get past most of the basics and toward things like this, the forum is the only place I can get help. Anyway, many thanks again!

@RT-Chris The limitation and also much of the complexity come from the situation that different abstractions write to the same file. So before overwriting existing data, they first have to read the data and add their own data. If the file does not exist there will be an error message.

This could be better solved with a centralized saving mechanism that doesn't have to be that complicated. The above was more a fun project to show that it is possible. The centralized approach is much more straight forward.

@ingox Thank you for building these (in the getdir format too!), it's honestly saved me so many frustrated hours clambering around and slowly debugging my way in the dark...

Totally agree about the centralised saving. I had wanted abstractions to have multiple preset states, but that can be achieved by multiple centralised saves too, just don't change everything else in the patch

Sorry to ask as you've been more than helpful enough already, but just have a couple of questions about the centralised patch you've built as I'm still trying to understand it (I think I'm still on a steeper part of the PD learning curve than I had thought/hoped!)...

To have a series of numbered saves, should I adapt the [append /array] to something with variables [append/array$2-name], or should that be in the concat function using [makefilename]? (I also was curious what the %g is in the makefilename, as I can't find any documentation of it).

I'm amazed the array saves automatically as a text file without declaring .txt. Following form this, am I right in assuming to read the series of saves I set up the same function and just replace write with read?

And finally (sorry!), as I understand the [const 0< [const 1< are examples of different arrays that are consolidated into the single $0-buffer. As there will be multiple arrays. is the order in which they are saved important? or is this where routing is a useful option (think you mentioned it before somewhere, maybe an earlier post)?

Thank you so much again, you've been really extraordinarily helpful!

@RT-Chris Well the above is not the centralized approach.

Here is an example of a save mechanism that is controlled by the main patch:

save.zip

It is much more simple. In the abstraction the data is prepended with selectors and on retrieval sorted via [route]. I think this principle would always be the way to go, although there are other ways to implement the mechanics. In addition there is a selector for the set, so different presets can be saved in the same file.

Since the abstractions are tagging their data themselves, this is quite flexible. Therefor the text search to see if the selectors are already in the file.

@RT-Chris It is also possible to build a preset system using [savestate]. This does further simplify the code and doesn't need any text file for the data.

savestate_presets.zip

So here the abstractions are maintaining their data themselves within a [text] which is saved by [savestate] into the main patch.

@ingox Thanks, these are really really great! Bit busy over the weekend, but trying to unpack this now. Think I misunderstood the "save in main dir" file as a centralised form, so apologies for that. The second most recent file "save.zip" that actually does this is really great, thank you. It's very clear and so much easier to implement than what I was trying to make work.

@RT-Chris If you want to integrate different abstractions you can also add another selector for each abstraction. Selectors can also be symbols, so you can just use the name of the abstraction. Then you can use the abstractions in different projects and it will still work.

@RT-Chris There is a [list split] missing before [text search]. The length of the list to [text search] should only be as long as the numbers of fields used to search.

(Now updated)

@ingox Yes! Took me a little while and some confusing cross talk but I realised after some debugging that in each abstraction I needed to prepend with an additional selector, and figured Symbols were better for debugging purposes too.

And you're there ahead of me on the text too - I was going to mention the input accumulates rather than overwrites (which although maybe unintentional acts as a kind of save history), but did wonder if that was going to cause some erratic behaviour sending multiple sets of information. Thanks very much (again!) for your update, I would have been a while tying to figure out how to fix that