Hallo, I suppose this question is for Frank, though maybe others have already found the solution.
I have converted all of my abstractions to use Memento, and I'm following the rradical design style so that I can build complex patches, then save their entire states. Samplers, oscillators, sequencers, envelopes, it's all working wonderfully. But! Often I've wanted to just save one unit's settings without grabbing the entirety of my opened patches.
I'll describe my setup first, and make an example if it is not sufficient.
Unnecessarily verbose description follows: I have a sampler unit with speed, loop points, interpolation, crossfades and so on (based on the lovely xgroove, thanks Thomas!). I usually load up 16 of these to use with drum pads, named like /sampler1, /sampler2 etc. It would be awesome to be able to set up one of these units with all these parameters (say, a sound loop, trimmed to 1 event, played at 3/4x speed, with no loop), and then save that setup for later.
Then later, my 16 samplers are open, and 12 are active with a nice setup. Now I want to load that drum loop with those settings (my event, 3/4x speed, no loop) without affecting the other 12 sample units.
I know that if I load up a blank patchwindow and setup, say, /sampler7, and save, I'll end up with a settings file with just /sampler7. But (A), that method would only be useful if I pre-planned the setup (what if I want to save a single instance after I've setup many others? (yes, I could trim the file manually : ) )). And (B) that saved file is only useful for a sampler labeled /sampler7, so it can't be arbitrarily loaded into /sampler15 (again, short of editing the file).
So! If I haven't proven myself completely inept at implementing memento, is there a method for this? I believe it is possible (I think a very specific request to the RRADICAL pool, plus a restore that ignores the original labelname and substitutes the current labelname...), but I guess Frank will have an insight before I can type a single [list append] : ).
(Further: I think that I could use SSSAD or rig up something external to memento, but it would be pretty excellent to have a system that was capable of both so that I am not rigging up multiple commun-like objects to every control!)
Regards, Luke
Hallo, Luke Iannini (pd) hat gesagt: // Luke Iannini (pd) wrote:
I have converted all of my abstractions to use Memento, and I'm following the rradical design style so that I can build complex patches, then save their entire states. Samplers, oscillators, sequencers, envelopes, it's all working wonderfully. But! Often I've wanted to just save one unit's settings without grabbing the entirety of my opened patches.
Acutally that is what the "svxdir/ldxdir file.xml" methods of [originator] were supposed to handle. The approach was to have it work like in attached example patches. For debugging purposes the commands sent to the internal [pool] are still printed into the console. However it doesn't work. :( Probably I'm misunderstanding how the pool-methods svxdir/ldxdir are supposed to work. According to the pool-help.pd they should save and load the contents of the current directory. However what they actually do save and load is a full tree, including the toplevel name. Until pool gets a method (or until I find the existing method of pool) that really only saves the content of a directory and nothing else I'm afraid there's no way to easily save and load local states. (You could of course build your own local-saver...)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Acutally that is what the "svxdir/ldxdir file.xml" methods of [originator] were supposed to handle. The approach was to have it work like in attached example patches.
You know why...
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi Frank, thanks for the implicit bug report. I think that svxdir/ldxdir also work for you, but there's a small badly documented thing: If absdir=1, absolute folder paths are written into the XML files, which make it impossible to correctly re-import the files with ldxdir, which only loads the first level. ldxrec would load more levels. On the other hand, with absdir=0 svxdir stores relative folders.
Please find the attached example which should clarify things.
best greetings, Thomas
Acutally that is what the "svxdir/ldxdir file.xml" methods of [originator] were supposed to handle. The approach was to have it work like in attached example patches. For debugging purposes the commands sent to the internal [pool] are still printed into the console. However it doesn't work. :( Probably I'm misunderstanding how the pool-methods svxdir/ldxdir are supposed to work. According to the pool-help.pd they should save and load the contents of the current directory. However what they actually do save and load is a full tree, including the toplevel name. Until pool gets a method (or until I find the existing method of pool) that really only saves the content of a directory and nothing else I'm afraid there's no way to easily save and load local states. (You could of course build your own local-saver...)
Ciao
Hallo Frank, I am working on fixing this up thanks to Thomas's explanations... Is there any reason you used the xml format for local saving? I was going to put it back on regular pool datafiles to be consistent with "main" memento.
I believe I have things going the way they should! But I'd like to do a little more testing and make a nice (miniature) GUI for inclusion in local patches.
Luke
On 3/4/07, Thomas Grill gr@grrrr.org wrote:
Hi Frank, thanks for the implicit bug report. I think that svxdir/ldxdir also work for you, but there's a small badly documented thing: If absdir=1, absolute folder paths are written into the XML files, which make it impossible to correctly re-import the files with ldxdir, which only loads the first level. ldxrec would load more levels. On the other hand, with absdir=0 svxdir stores relative folders.
Please find the attached example which should clarify things.
best greetings, Thomas
Acutally that is what the "svxdir/ldxdir file.xml" methods of [originator] were supposed to handle. The approach was to have it work like in attached example patches. For debugging purposes the commands sent to the internal [pool] are still printed into the console. However it doesn't work. :( Probably I'm misunderstanding how the pool-methods svxdir/ldxdir are supposed to work. According to the pool-help.pd they should save and load the contents of the current directory. However what they actually do save and load is a full tree, including the toplevel name. Until pool gets a method (or until I find the existing method of pool) that really only saves the content of a directory and nothing else I'm afraid there's no way to easily save and load local states. (You could of course build your own local-saver...)
Ciao
-- Thomas Grill http://grrrr.org
#N canvas 531 166 841 775 12; #X obj 140 663 print K; #X obj 91 692 print V; #X obj 189 637 print D; #X text 262 637 directory (abs or rel to current); #X text 166 693 data value; #X text 212 663 data key; #X obj 162 482 r $0-pool; #X obj 288 585 print A; #X text 360 584 attributes; #X obj 242 611 print C; #X text 314 611 command; #X obj 196 584 route bang; #X obj 401 698 print ------------; #X text 405 678 separator on bang; #X msg 191 208 mkchdir $1-dir; #X obj 164 404 s $0-pool; #X obj 140 215 until; #X obj 140 242 random 1000; #X msg 140 277 set $1 $1; #X msg 60 72 reset; #X msg 474 413 printroot; #X msg 155 72 1 , 2 , 3 , 4 , 5; #X obj 162 510 pool; #X msg 476 154 absdir 0 , chdir 3-dir , svxdir test.xml; #X obj 155 128 t b f; #X text 59 46 1)clear; #X text 165 49 2)populate; #X msg 140 188 5; #X text 479 50 3)save; #X text 479 80 write absolute paths into file; #X text 477 134 write relative paths into file; #X text 474 234 only load one level of the XML file; #X text 475 296 load all levels of the XML file; #X msg 478 101 absdir 1 , chdir 3-dir , svxdir test.xml; #X msg 474 257 reset , ldxdir test.xml; #X msg 473 315 reset , ldxrec test.xml; #X text 477 213 4)load; #X text 475 392 5)print; #X connect 6 0 22 0; #X connect 11 0 12 0; #X connect 11 1 9 0; #X connect 14 0 15 0; #X connect 16 0 17 0; #X connect 17 0 18 0; #X connect 18 0 15 0; #X connect 19 0 15 0; #X connect 20 0 15 0; #X connect 21 0 24 0; #X connect 22 0 1 0; #X connect 22 1 0 0; #X connect 22 2 2 0; #X connect 22 3 11 0; #X connect 22 4 7 0; #X connect 23 0 15 0; #X connect 24 0 27 0; #X connect 24 1 14 0; #X connect 27 0 16 0; #X connect 33 0 15 0; #X connect 34 0 15 0; #X connect 35 0 15 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Luke Iannini (pd) hat gesagt: // Luke Iannini (pd) wrote:
I am working on fixing this up thanks to Thomas's explanations... Is there any reason you used the xml format for local saving?
Not really. AFAIR there were some problems with local saving in normal mode, so I tried the XML mode, but that's several months ago, so I don't really remember and I should try again.
I was going to put it back on regular pool datafiles to be consistent with "main" memento.
Yes, if it works, that's better.
I believe I have things going the way they should! But I'd like to do a little more testing and make a nice (miniature) GUI for inclusion in local patches.
Cool. I'll include it then.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
Luke Iannini (pd) -
Thomas Grill