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

[Thomas O Fredericks]

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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>