I use a lot of VST~ and make custom programming for one shot installations. I want PD to remember what vsts I loaded and what program number was last selected. They have to be loaded as if they were actual PD objects. Automatic loading of a default state file just makes life simpler. In that state file you could have many presets, but the state file IS necessary because some things are REQUIRED to load before making the patch functionnal.
Of course I can do it like as Charlie suggests, but that is to much hasle and hard to teach to beginners
Tom
Christopher Charles wrote:
hi list.
Frank Barknecht wrote:
Hallo,
Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
For state saving: I would like to create an abstration that saves an XML file (with the help of pool and memento for example) in the same folder as the parent patch. The file would have the same name except for an appended ".xml". That way, once you reload the patch, it reads the xml file, and voilà , your settings are restored.
What do you think about this aproach?
My opninion about using patch names as statefile names is mentioned sometimes in the archives: I don't like it, it's not the way, I think about what a pd patch is. I consider a pd patch to be its own application, which was built using Pd instead of, say, C++. Presets in a pd patch then are like working files of this application. Assume you have a Pd application called "WORD.pd" then this could use all "*.doc" files everywhere as working files - like MS Word and Word-doc files.
However it is a bad idea to enforce the basename of the working file. What use would WORD be, if you could only save one file and this file would always have to be called "WORD.xml" and it would need to be in the same directory as the WORD.exe?
Now your approach is slightly different, in that you use another file just for restoring settings. I don't see the need for this extra file yet, though.
okay, nobody asked for it, but here's my approach in state saving: in my bagoftricks (bot) abstraction collection i store all the relevant info for loading into messages. a typical bot patch is just a .pd file, which contains information about which bot abstractions are used, and which messages are fed into them at startup. for example: in my patch i have a drum machine abstraction, on it's right, there is a subpatch(e.g. [pd s]) crossconnected, containing an inlet, outlet, a message and a loadbang. everytime the patch is loaded, the loadbang kicks the message into the drum machine, everytime sliders in the drum machine are changed, a newly created status message is sent to the message box in the subpatch via a "set" message. this way, the patch itself becomes the savefile. it's a bit of a hassle to adapt all the abstractions to this behaviour (especially when the abstractions have loads of sliders...) but it works to save all the needed info in the parent patch, and what's best, no additional dependencies (such as pool) are needed (well, i often used [iem_prepend set] in my abstractions, but those could all be substituted with [set $1 $2 $3...etc( messages). second point i don't like about this solution is that the parent patch is crowded with a number of [pd s] subpatches, but i got used to that. it's not ideal, or universally applicable, but just meant to be a basic, convenient state saving system, nothing too complex, with no additional user interaction needed than to load and save the parent patch.
if you're interested, grab the current bagoftricks from https://puredata.info/Members/syntax_the_nerd
the state saving is explained in detail in the first tutorial patches that come with it.
charlie/stn
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list