[PD] The parent patch file name... state saving

[Christopher Charles]

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