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

This is very nice, and the documentation is very clear. I love that it can be used in an abstraction locally to send the values out to the parent patch. The preset example is exactly what I was building for sssad, but I think I'll switch to this....alot simpler and flexible.

Thanks! I've had these for a while, and I wasn't sure if they were actually useable, or if they seemed usable to me because I wrote them. It's taken me a while to get the courage to release them, since I know a lot of people think sssad is the way to go. But sssad doesn't seem like a project that gets much dedication to me, and that's, well, sssad. (I fucking love puns, you guys!)

But seriously...I think easy state-saving is something that Pd needs. Newbies (understandably) want it right away, but it's not something you can easily do right away. So any feedback you guys have on this, please give it to me. I'd like to make this into a serious project. I've been thinking about trying to put my library in Pd-extended, and I think these abstractions would be a great addition, if they turn out to be really useful.

I'm glad you did release it!

I'm working on a sampling patch that would really benefit from this as a preset system. I'll definitely let you know how I use it once I build it out over the next week or so.

@Maelstorm said:

But seriously...I think easy state-saving is something that Pd needs. Newbies (understandably) want it right away, but it's not something you can easily do right away.

I've been using PD for about two years now and didn't realize state saving was possible (except via arrays and text files) until combing the forum recently. I'll definitely take a look - briefly looking at sssad was rather confusing and seemed to require many objects.

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

@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