Hey guys,

I've put together a couple of abstractions that hopefully will help simplify state-saving a bit. I think these are pretty simple to use. There are only two objects: [save.me.mmb] grabs individual parameters, and [my.hero.mmb] collects them all and outputs them into a nice message box.

I've tried to show some basic and not-so-basic ways of using these in the help patch, including making in-patch presets, storing presets to a file, and saving abstraction parameters in the parent patch. If there's anything you think I should add to either the documentation or the functionality of the abstractions themselves, let me know.

http://www.pdpatchrepo.info/hurleur/save.me.mmb.zip

One other thing I've noticed...

If we take, for example, 'dump-example.mmb'... When I click dump, it only saves slider values that have changed since the last time I saved. What I really need is a snapshot of all slider values that I can store as a preset. If all slider values are not saved, the preset isn't very useful, as when I load it it doesn't represent the complete state of the object. The problem persists even if I use 'save2.'

It's possible I'm doing something wrong, but I don't think so...

You mention above that "if there's anything you think I should add to either the documentation or the functionality of the abstractions themselves, let me know."

Well, if I'm right, and this is in fact how the abstractions currently work, it'd be nice if they provided for an actual 'dump' message that would record the value of everything hooked into the save.me.mmb in question. If that's too much hassle, maybe just explain a way to actually dump all params hooked up to a save.me abstraction.

And if in fact I've broken something, please accept my apology. I had to hack a bit to get this running with pd-vanilla...

Thanks!

For the automation question, it depends on how you do it. If you are basically just saving breakpoint data for [vline~] to follow, for example, then these would work great for that. But if you are thinking about constantly updating by sending a [load( message at each tick, then they would be terrible. A better solution would be to record the automation into a table and save that with the other parameters.

As for your other question, I don't have the same issue. If any slider has been changed since the patch is loaded, it will be saved when you hit the [save( message. The only ones that don't get sent are the ones that have never been adjusted. You could just connect a [loadbang] to all of the sliders in [dump.example.mmb]. I typically just have a [pd init] in my abstractions that sets everything to a default state, which also makes sure there is a value stored in each [my.hero.mmb].

And if in fact I've broken something, please accept my apology. I had to hack a bit to get this running with pd-vanilla...

What!? These are supposed to be vanilla friendly. What did you have to do?

"The only ones that don't get sent are the ones that have never been adjusted. You could just connect a [loadbang] to all of the sliders"

That's what I ended up doing.

"What!? These are supposed to be vanilla friendly. What did you have to do?"

Sorry - hack was a strong word. I had the same issues ([prepend], [tabdump], and [tabset]) as the guy above... Any other issues I had were my own fault as I worked to refactor what you've made to work in the system I'm developing.

These are very helpful abstractions. Thanks again!

@shmimpie said:

Sorry - hack was a strong word. I had the same issues ([prepend], [tabdump], and [tabset]) as the guy above...

Oh, right. That's just for the helpfile. The abstractions themselves are all vanilla. One of these days I'll get around to making a vanilla version of the helpfile.

This is really usefull, thanks.

Looking at the pd preset.system in your help-file I was wondering if it would be hard to have another knob which can "morph" through the previous saved states.
I've seen this in a plug in called Redupcer. but I'm a beginner in Pd so might be a headache.

[line] could help here

... maybe like this

http://www.pdpatchrepo.info/hurleur/morph.my.hero.mmb-help.pd

cool, I was actually thinking that i'd need the pack object. I'll try to tweak this so i can change morphing-index with a knob.

i actually noticed maelstroms link "My Library".
What a wonderfull pure data world!

Is there a way to recall strings including spaces with the [my.hero] abstraction? Instinctively i tried to wrap a longer string in single / double quotes but that doesnt work. I would like to load a descriptive text for presets, which would be kind of messed up if i wrote it without spaces or underlines instead of spaces...?

Once the patch is reloaded, Pd parses the spaces out so it ends up being a list of symbols instead of one long symbol with spaces. You can use [zexy/list2symbol] at the output of [save.me.mmb] to convert it back to a symbol with spaces.

Hey Maelstrom, do you have a complicated patch that use this with? I'm just curious at organizing the layout of the patch while including these new objects that have to go everywhere.

Thanks for this, these are amazing!

Hey Maelstrom, I'm using $0 on a lot of my objects in my patch and I got save.me and my.hero to work, but when I load a file, it loads with the old number from $0. I just go in and do a search an replace in the text file, but I was wondering if it's something you've already addressed or should I not be using $0s so often?

Thanks!

What parameter are you saving that needs $0? Since $0 is specific to an instance of a patch, it doesn't really make sense to have it as a parameter value to be saved in a preset. Presets should be loadable in any instance.

Oh, and I do have some fairly complicated uses of these, but the patches aren't quite shareable yet. But almost everything I've done with these is just bigger versions of what's outlined in the helpfile.

Hello people. Just a reminder to check some abstractions for presets management that I've recently posted:

http://puredata.hurleur.com/message-37768.html#p37768

Thank you in advance for the feedback.

Sumidero