Hi, this question has been unanswered: How can I get the filename of the parent patch (like getdir or pwd does for the directory of the parent patch)? Why do I want this? 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?
Tom
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.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "plak" @ http://footils.org/cms/show/44
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
Hallo, Christopher Charles hat gesagt: // Christopher Charles wrote:
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.
Yes, this is a different approach than mine. It is more "traditional" in that a state is saved inside the/a patch using a message and loadbangs. The beauty of it of course is that it is simple and just works. Actually it's the way I also use for "one-off" or "throwaway" patches. And it also is the way used in Pd, when you are using data structures as the "score".
However for example I have one patch which I use when doing "party sets" (see http://footils.org/cms/show/36) where the music is dancy house music. The patch there is always running and contains various instruments like a drum part, a "soul diva sample" part, a "phat bassline" part etc. and sequencers controlling all that. Then I load a big preset for lots of songs into the Memento pool and play along with these for as long as the audience lets me.
With that it is much more useful not to have the sequences stored inside the patch, as the patch will stay the same all the time, but the sequences, the *songs* will change. OTOH I don't want to change the songs when I'm doing changes to the patch. So having both the presets and the instrument as different thing is crucial to me. (Like having a piano on one side and different score sheets on the other in traditional music.)
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).
... or now use [list prepend] with pd-0.39.
BTW: To save a bit of patching work, I'm currently experimenting with dynamically generated state saving elements for Memento. For those interested, I attached the current state of affairs with this. The "dynamic-commun" part of this will later go into [originator] itself.
Then instead of creating a lot of [commun] objects by hand, this work can be replaced by sending special messages to [originator] itself as illustrated in dynamic-commun-help.pd
The attached files require a working installation of Memento. Then just drop the three new patches into your Memento directory and open dynamic-commun-help.pd
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
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
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
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.
Well, why not just use a [loadbang] to load the state file. I do this a lot. You may need to specify the full path because of Pd's way of handling paths or use the "path finding" externals mentioned here in the past (I don't remember their name, something like "pwd" or "getdir") to get the name of the patch's directory.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
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.
Well, why not just use a [loadbang] to load the state file.
Ah, sorry, I now see how this is related to your original question, where you wanted to save and reload using the name of the *parent* patch.
I see no other solution to that than to use "getdir" in the parent patch and pass that to the child through a message or as argument. The parent knows it's name, either by "getdir" or by hardcoding, so this should work.
However I still think, that relating patch filenames to state files is not The Right Thing, to me it just feels wrong. But I had this argument with Ben Bogart several times (remember, Ben?), so I can understand that people want to do it. I just think it's wrong. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Getdir only outputs the directory in witch the parent patch is and not the parent patch name!
Tom
Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
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.
Well, why not just use a [loadbang] to load the state file.
Ah, sorry, I now see how this is related to your original question, where you wanted to save and reload using the name of the *parent* patch.
I see no other solution to that than to use "getdir" in the parent patch and pass that to the child through a message or as argument. The parent knows it's name, either by "getdir" or by hardcoding, so this should work.
However I still think, that relating patch filenames to state files is not The Right Thing, to me it just feels wrong. But I had this argument with Ben Bogart several times (remember, Ben?), so I can understand that people want to do it. I just think it's wrong. ;)
Ciao
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
Getdir only outputs the directory in witch the parent patch is and not the parent patch name!
But then:
[getdir] | [makefilename %s/PARENT_NAME.pd]
will work, as you know the PARENT_NAME anyways.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
Getdir only outputs the directory in witch the parent patch is and not the parent patch name!
But then:
[getdir] | [makefilename %s/PARENT_NAME.pd]
will work, as you know the PARENT_NAME anyways.
Ah, sorry, I'm talking nonsense again: "getdir" gets the name of the *parent*, right? (I don't use it). Well, then of course the filename indeed is unknown and would need to be passed as argument then. Or maybe one could change getdir.c to also send out the parent's filename
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hello all, my 2 cents:
What I've done is coordinate the initialization of multiple instances of the same abstraction in a parent patch with an argument, as $1:
[loadbang] | [$1] | [sel 0 1 2 etc] | | [; init a( | [; init b(
etc., so that different states can be automatically loaded based on the initialization arguments assigned to it in the parent patch. This works fine for me. Does that make sense?
David
From: Frank Barknecht fbar@footils.org To: pd-list@iem.at Subject: Re: [PD] The parent patch file name... state saving Date: Tue, 6 Sep 2005 17:37:46 +0200
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
Getdir only outputs the directory in witch the parent patch is and not the parent patch name!
But then:
[getdir] | [makefilename %s/PARENT_NAME.pd]
will work, as you know the PARENT_NAME anyways.
Ah, sorry, I'm talking nonsense again: "getdir" gets the name of the *parent*, right? (I don't use it). Well, then of course the filename indeed is unknown and would need to be passed as argument then. Or maybe one could change getdir.c to also send out the parent's filename
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Christopher Charles -
david golightly -
Frank Barknecht -
Thomas O Fredericks