Hi there,
I have long been looking for a simple way to save presets that could be quickly adapted to a new patch. After many failed attempts I have devised this method which for now seems to work, it's all vanilla and doesn't require any patching as such, though it does require that all the control parameters to be saved are in the same patch (the main patch) and that their send and receive symbols are formatted in a coherent way. There is more of an explanation in the save.param-help file, but it's really quite simple. Perhaps someone has already come up with something similar but I couldn't find it.
I hope someone might find this helpful in some way and I'd be very interested to hear if you have any suggestions and improvements.

save.param.zip

@weightless I do have an example, but the patch is complex (its a 64in /64out monitor mixer controlled by OSC messages)............ and large and incomprehensible. I am trying to write a pdf manual before I make it public. I have been using it for live performance for a couple of years but trying to explain it is very hard. I am not really sure how it works sometimes!!!
I use [slist} quite extensively for saving presets within that patch. If you look at the help file (for slist) you will see that it provides a method for interrogating a shared list.
So.......... if at {loadbang] you import your textfile data using [iem_pbank_csv] you can write that data (at loadbang) to [slist] (s) using a sequenced [add2] until the end of the textfile and then use it wherever you wish as [slist] "is" a "shared" list.
You can also write the text files using [iem_pbank_csv] by writing lines within the text file using [pp] or [prepend], setting the parameters per line of text, and setting the file length to the number of groups of parameters that you need.
I use it throughout the patch for preset saving and recall....... all level, eq. etc settings and all names of playback tracks etc. etc......... everything.
I will try to make an example, and if I don't manage that then I will post my patch anyway...............
It might take a few days.....
ALSO........ it could be that your patch will do more or less what [iem_pbank_csv] will do...... in which case you will have moved closer to vanilla than me. If [slist] can be vanilla-ized then you will help me get closer to a universal patch for my projects. I think this thread might run (between us) but progress could be sloooowww.....wiiish...................
David.

That would be great, but if you plan on releasing your mixer patch anyway (which sounds very interesting indeed) then it's fine I will have a look at the preset system then. For now thanks for the heads up on those two objects, I will look into them and see what I can make of them.
m

@whale-av, @weightless: help file for [mmb/my.hero.mmb] includes an example of saving presets into a file ([pd save.to.file]): https://raw.githubusercontent.com/dotmmb/mmb/master/my.hero.mmb-help.pd

@lzr thanks for the tip, I had a quick look and yes, it does look like I've reinvented the wheel on that one. When I have some time I will look into it more to understand what it does, and see if I can improve my patch or dump it altogether and use that one. I also really like the idea to be able to save the parameters coming from abstractions.

Haven't looked at your patch but just to chime in a few cents:

This issue came up for me when designing a MobMuPlat app and what worked nicely (particularly in that environment where write access is VERY limited if at all (in which case I precreated the save files)) was scale all the control values to 0-1 and acct for it at the write "function" side (could really be and perhaps even better as -1-1) and write them to an array.

Then just dump the table to the file or retrieve back via message/object/pack/unpack.

Worked great and was very clean.

As I say this was really useful on iPhone and Android where libpd or the OS won't let you create files.

what made it even cooler was you could then mix and match combinations, ex. pre presets to post presets.

ciao. food for thought really I suppose. when I'm at laptop tomorrow will see how you did it.

peace

Hi Svanya,
thanks for your suggestion, I'm not sure if I understand completely the process you described but I had tried to save values to a table, although what I didn't like is that if you want to have a lot of different presets you need different tables (I think?), and even in that case the number of presets would be pre-determined. Since saving to a textfile in pd seems easy enough, I liked the idea of having one file for each preset.
Anyway, if you have an example of how you did it I'd be interested in taking a look at it.
Thanks,
m

@weightless Hello weightless...... here is a bit of a much larger patch that saves all of the parameters to text files as presets......... for extended.
I was a seriously nooby when I wrote it, but I have never had the time to revisit and revise the patches..........
They are reasonably tidy though, and maybe there are some clues for you in there somewhere...... so here goes.......... open "top_patch.pd" and play...........
list storage.zip
p.s. the terminal tells you which files are being written and read. If you change parameters and send a new name to [s save_busses] it creates a new file with that name.......
David.

@weightless you could save your table as .wav file and load it as such easily with soundfiler. Does not matter whether you want to listen to your presets, or want to use them sample by sample. I use preset saving of mmb and sssad with textfiles, both work good and fast!

@weightless
I've attached the two main subpatches I used to read/write the presets.

It's not an abstraction, so clunky, but it did allow for a lot of versatility: it writes the saved states as as a set of presets (one per table) with a the same date+time stamp for each one, which then allows you to load either the entire state or just one control's/tables values.

Hope there is something in it that you can learn from or get ideas from.

It's dependent on zexy (to write the filenames as date+times).

"save_state" writes the contol values to the tables (i used arrays as controls which works great with MobMuplat, since it sends a list of values for its multisliders) and "update_controls" reads the tables and updates the table and subsequently the subpatch (which in this case are guitar effects/pedals) controls with those values. "update_controls" also scales all the values in the tables from 0-1 to whatever the effect's controls are limited to.

As I mentioned before makes more sense to me now, to have the tables/multislider controls be from -1 - 1 and 0 be the default value, but such is life .

-peace
svanya

save_state.pd
update_controls.pd

also, sorry, they are/may be hard to figure out: the rig was to have 13-14 pedals in it. so it called for a lot of tables.

Hi Weightless,
Thank you millions for this patch! I don't think you have reinvented the wheel at all. I have been looking for all the possible ways to do it to avoid the ridiculous amount of conditional changes and dynamic variables which in PD means hundreds of Spigots and set messages and list wrappers.... I don't know if I am being ignorant but your solution is the simplest and more elegant I've seen so far. And the presentation for others to implemented is spot on. I have already integrated in my patch and love it! Honestly, brilliantly put together as an easily attachable module and very kind to sharing it here. I will share my patch with your system incorporated when I finish tidying it up, I also loved Johnny Mauser's solution of using audio files, very clever indeed I would have definitely gone with that one if you did;t come with yours as, like you sid, the ability to work with a text file is unbeatable. for this type of implementations. Cheers,!
Ricardo

I have updated the patches to use the new [text] object instead of [textfile], which should be more versatile, and also now when a preset is loaded into the [text define] buffer it is possible to do searches from within pd , so perhaps it's also closer to what @whale-av suggested with using [slist].

I've also added the [save.array] abstraction to save the content of arrays as well, should that be needed.

save.param2.0.zip