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

@PonZo said:

Anyhoo, it'd be great to save states via a save-panel but then retrieve them with a [popup] to avoid the open-panel.

If you save your files in the same folder, you could use [folder_list] to populate [popup].

Oh, thank you for directing me to folder_list - I actually have been dreading loading up drum samples into arrays but now it will be much easier!

Hi Maelstorm,
Thanks for releasing these, very helpful. However, I'm using vanilla, so I'm missing [prepend], [tabdump], and [tabset]. I already had an abstraction for [prepend], but I'm not sure what the exact functionality of the other two are in order to vanillize them.
This is not a big deal since I can just click the 'save contents' check box, but for completeness it would be nice to be able to use this system to save whatever in a vanilla type environment.
If you could explain what those tab objects do, I could try to abstract those too, and then post a vanilla version. Do they convert lists to tables, or deal with a stream of numbers, like [until]->[counter]->[tabread]?
I attached the prepend abstraction in case anyone wants it.

http://www.pdpatchrepo.info/hurleur/user_prepend.pd

Yeah, [tabdump] creates a list out of all the elements in a table, and [tabset] fills a table with a list. You can easily replace [tabset] by taking the list and prepending it with a 0 (first index of the table) and sending it to the table:

[1 2 3 4 5 6(
|

|

Just to be clear, though, those are just for the help files. The abstractions themselves are vanilla-friendly.

BTW, you can simplify your abstraction by doing this:

[inlet]
|
|
|
[outlet]

Cool, thanks. It's funny, I could swear I tried

before I came up with that nasty hack, but there it is, right in the help file. I made that one a few years ago, so it's hard telling what my logic was at the time.

Thanks again for the state saving abstractions. You rock.

@Psyko said:

Thanks again for the state saving abstractions. You rock.

\m/

Also, I forgot to mention before, but the list-abs library, which aims to be vanilla-friendly, has a version of [tabdump] called [list-tabdump]. Might save you the trouble of making your own version.

Hi Maelstorm,

I'm using these abstractions and they work great!

I'm wondering if I'd be able to use them for automation - in other words, saving state over time.

Can you think of a way to do this? I'm new to PD, so I'm just looking for a nudge in the right direction...

Thanks!

Can you elaborate on what you want to do?

All of the major audio packages (ProTools, Logic, etc.) support automation - they let you write (and play back) changes to parameters over time.

Until now, that hasn't been in scope for this project, and it probably still isn't... But your nice abstractions made me start to think about it.

I think it'd be pretty tricky. For one, there's the question of the density of the data - how much would you need to read / write to get the job done?

What are your thoughts?

thanks...

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!