# Hi everybody! # I tried to build an abstraction which remembers its previous state before closing the patch. I put an array in the abstraction with its "save contents" option checked and saved the state of the abstraction in this array of which name starts with $0- in order to make each table unique. A [loadbang] outputs the values stored in the array. # But this doesn't seems to work. I made an example of this structure. abswmem.pd is a very simple abstraction, and test.abswmem.pd have two of them. After giving the arrays of the abstractions different values, saving the patch, closing it, and loading again. Nothing happens :-) The values aren't stored in the arrays. # And I see the ambiguity. There is only one .pd file for the abstraction, so, only one file for storing the values of the array. Which abstraction object's array will be saved etc?
# Can anybody help with these? -ugur guney-
I think you're confusing a pair of details:
# I tried to build an abstraction which remembers its previous state
before closing the patch. I put an array in the abstraction with its "save contents" option checked and saved the state of the abstraction in this array of which name starts with $0- in order to make each table unique. A [loadbang] outputs the values stored in the array.
first, the values don't get stored in the arrays, because to do so you
have to save the abstraction with the modified array. that only works when
you open up each abstraction and press ctrl-s, or if you would send a
pd-abswmem.pd menusave message - which usually works, but with
abstractions makes pd work at 100% cpu and forces me to terminate the
program.
second, each patch has it's own $0 identifier, which will make each
abstraction unique. but if you save the abstraction itself with any stored
value, it is still only one file, which will make all abstractions to open
up with the same stored value. in this case the $0 will be of no help,
because you're not using it.
# And I see the ambiguity. There is only one .pd file for the
abstraction, so, only one file for storing the values of the array. Which abstraction object's array will be saved etc?
you could save each array into it's individual text file, and retrieve it
back later (with the write/read messages, consult all_about_arrays.pd) -
an external file to serve as memory should be the only sollution here. but
then you must make the mechanism which will make each abstraction know
which is its file. I think it would be more confortable to make one table
for a whole patch (that's how I usually work).
this has been a topic in these last days. look the archives / web for
memento, ssad, rradical, these seem to be the main mechanisms for this
kind of operation, and they seem to be very good (I never used them).
Joao
After giving the arrays of the abstractions different values, saving the patch , closing it, and loading again. Nothing happens :-) The values aren't stored in the arrays.
if you save the patch it won't automatically save the abstraction. but you want to store the data in the abstraction and use this abstraction more than one time... ...i see no way that could work. sorry
eni
Hallo, sokratesla hat gesagt: // sokratesla wrote:
# I tried to build an abstraction which remembers its previous state before closing the patch. I put an array in the abstraction with its "save contents" option checked and saved the state of the abstraction in this array of which name starts with $0- in order to make each table unique. A [loadbang] outputs the values stored in the array.
Your approach has some pitfalls. First: If you use an abstraction in a surrounding patch and then save the surrounding patch, the abstraction itself won't get saved. Second: Even if you save the abstraction by hand, if you use two of them, then after saving both will have the same value stored. This is probably not what you wanted. $0 won't help you here, because in a saved patch, it is just that: "$0". The last actual value of $0 of course isn't saved and you cannot rely on getting the same value again if you open the patch again.
The only good way to save settings of (maybe nested) abstractions is to intercept some or all messages that their objects generate and collect them in a globally accessible space like a textfile, a global array, global data structure subpatch, global message object, global [pool], [coll], [msgfile] or whatever. This global saver in the end has to be outside of the abstraction whose state you intend to save. To differentiate between abstractions of the same type and file you will also need to give them ids or tags. I generally abuse $1 for this.
[sssad], which was mentioned here several times, tries to be an easy to use, general purpose "message interceptor". ([commun] in Memento is similar, but specific to Memento.) In itself it doesn't deal with the actual state saving. In the sssad-package there is an example patch which does use a [textfile] for the saving, of course you could replace the textfile with a message box, if you want to. [textfile] and message boxes share almost the same interface, so it would be a drop-in replacement. Other candidates for saving include [pool] etc. But regardless of what you use for the actual saving to disk, you will need to collect the state of objects first, and for that I made [sssad].
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Arrays are not the best thing to use for data persistence. Messages constructed using "set" and then textfiles are preferable. Alexandre Quessy just posted a method yesterday that implements a per patch memory. You might like to study the "bag'o'tricks" GOP abstractions to see another effective example of doing this.
On Tue, 4 Jul 2006 17:43:54 +0300 sokratesla ugurguney@gmail.com wrote:
# Hi everybody! # I tried to build an abstraction which remembers its previous state before closing the patch. I put an array in the abstraction with its "save contents" option checked and saved the state of the abstraction in this array of which name starts with $0- in order to make each table unique. A [loadbang] outputs the values stored in the array. # But this doesn't seems to work. I made an example of this structure. abswmem.pd is a very simple abstraction, and test.abswmem.pd have two of them. After giving the arrays of the abstractions different values, saving the patch, closing it, and loading again. Nothing happens :-) The values aren't stored in the arrays. # And I see the ambiguity. There is only one .pd file for the abstraction, so, only one file for storing the values of the array. Which abstraction object's array will be saved etc?
# Can anybody help with these? -ugur guney-
I had to do the opposite. My preset arrays were huge, and if I made any changes to my patch and saved it, next time I opened it Pd couldn't read the whole file, and all the connections on the main patch were lost. I put a message box stating [;presetmemory clear ;JI.pd menusave ;JI.pd menuclose( and that seemed to solve it.
You could make an abstraction that would keep memory for every instance, but $0 wouldn't work, only $1. Any two instances with the same argument would load the same. You could actually keep a separate subpatch where every save of an abstraction created a new subpatch within it containing all the data for that $1. Probably not real useful to anyone though.
On 7/5/06, padawan12 padawan12@obiwannabe.co.uk wrote:
Arrays are not the best thing to use for data persistence. Messages constructed using "set" and then textfiles are preferable. Alexandre Quessy just posted a method yesterday that implements a per patch memory. You might like to study the "bag'o'tricks" GOP abstractions to see another effective example of doing this.
On Tue, 4 Jul 2006 17:43:54 +0300 sokratesla ugurguney@gmail.com wrote:
# Hi everybody! # I tried to build an abstraction which remembers its previous state before closing the patch. I put an array in the abstraction with its "save contents" option checked and saved the state of the abstraction in this array of which name starts with $0- in order to make each table unique. A [loadbang] outputs the values stored in the array. # But this doesn't seems to work. I made an example of this structure. abswmem.pd is a very simple abstraction, and test.abswmem.pd have two of them. After giving the arrays of the abstractions different values, saving the patch, closing it, and loading again. Nothing happens :-) The values aren't stored in the arrays. # And I see the ambiguity. There is only one .pd file for the abstraction, so, only one file for storing the values of the array. Which abstraction object's array will be saved etc?
# Can anybody help with these? -ugur guney-
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, padawan12 hat gesagt: // padawan12 wrote:
Arrays are not the best thing to use for data persistence. Messages constructed using "set" and then textfiles are preferable. Alexandre Quessy just posted a method yesterday that implements a per patch memory. You might like to study the "bag'o'tricks" GOP abstractions to see another effective example of doing this.
Personally I think, saving state *inside* a patch is The Wrong Thing anyway, except for trivial things like [osc~ 440] or so. Anything else should go in a seperate file. I sometime compare this to using a text editor like Word or Emacs: It isn't useful to be able to only edit one single text document with software like this, so you save every text into a seperate file, but use the same program to edit them all.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, padawan12 hat gesagt: // padawan12 wrote:
Arrays are not the best thing to use for data persistence. Messages constructed using "set" and then textfiles are preferable. Alexandre Quessy just posted a method yesterday that implements a per patch memory. You might like to study the "bag'o'tricks" GOP abstractions to see another effective example of doing this.
Personally I think, saving state *inside* a patch is The Wrong Thing anyway, except for trivial things like [osc~ 440] or so. Anything else should go in a seperate file. I sometime compare this to using a text editor like Word or Emacs: It isn't useful to be able to only edit one single text document with software like this, so you save every text into a seperate file, but use the same program to edit them all.
Ciao
hi well, i have to disagree there. i don't see any objections to a mixed code/state file. if you only have one fixed synth (or whatever) patch with fixed effect-routes (as monolithic as word or emacs), then keeping the state in different files makes sense, but if you have a patch with a bunch of small modules/abstractions which can be chained in various ways, then the way they are chained (the order of the abstractions) is imo part of the state, too. most of my bagoftricks patches look radically different and i don't save copies of them with only some parameters changed. another bonus for me is ease of use, with clicking pd's save button, i save exactly what i'm working on at the moment, when i load it up later, it sounds the same. only one file to take care of. if you look around at the various music softwares around, you'll notice that their behaviour is very similar to this. an application of seperate file-statesaving within the realm of single file patches is the use of presets for single modules. i don't want to say one way of state saving is per se better than another, but it often depends on what kind of patches you use to determine which way is better suited.
charlie
Hallo, Christopher Charles hat gesagt: // Christopher Charles wrote:
most of my bagoftricks patches look radically different and i don't save copies of them with only some parameters changed. another bonus for me is ease of use, with clicking pd's save button, i save exactly what i'm working on at the moment, when i load it up later, it sounds the same. only one file to take care of.
If I press the "SAVE"-bang in my patches, all settings are saved as well. But: I can use the same patch with two or more states, and I can even change states on the fly. To me, this is a crucial advantage of saving to an external file.
Of course to each his own, but pressing a different "SAVE" to save the patch than to save the current state of the variable in my patch is no problem for me.
Additionally: I'm using Subversion to keep track of past versions of my patch. If the patch changes just because some sliders were moved, this ould create a whole lot of different patch versions when in fact the actual patch didn't change substantially.
Plus: I also manage state files in the same subversion repository. I can go back to an earlier state there as well.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Wed, Jul 05, 2006 at 04:51:26PM +0200, Frank Barknecht wrote:
Hallo, Christopher Charles hat gesagt: // Christopher Charles wrote:
most of my bagoftricks patches look radically different and i don't save copies of them with only some parameters changed. another bonus for me is ease of use, with clicking pd's save button, i save exactly what i'm working on at the moment, when i load it up later, it sounds the same. only one file to take care of.
Of course to each his own, but pressing a different "SAVE" to save the patch than to save the current state of the variable in my patch is no problem for me.
Sure, that is a really good way of working, but not everybody wants to patch like that. In my opinion if puredata had the following features then it would make it a lot easier to make patches that save their own state within the main .pd file and still be able to use abstractions for modularity, which is the way some people like to work.
[parentname] which when banged gives the name of the parent patch.
[savebang] which bangs each time ctrl-s is hit or "save" is selected
from the menu.
This would enable GOP abstraction units to save their internal data to the parent patch (or a sub-patch of the parent patch) whenever the patch is saved.
At the moment you are forced to work in the Frank B way; make lots of virtual machines that save their state to a file collectively or individually, and can have multiple states for one "virtual audio machine" configuration, or the Hans Steiner/Solitude way; make a big patch which uses data structures to save it's state/score but can't really use abstractions meaningfully within that framework.
They way I like to work, and obviously some others too, is for each patch to be a self contained score and instrument, but to have the re-use of abstractions available. This is currently pretty difficult, so I use [sssad] to save state (thanks for that!). It would be nice to be able to build something that allowed for this alternative.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
They way I like to work, and obviously some others too, is for each patch to be a self contained score and instrument, but to have the re-use of abstractions available. This is currently pretty difficult, so I use [sssad] to save state (thanks for that!). It would be nice to be able to build something that allowed for this alternative.
Btw: [sssad] can be used to save into message boxes instead of [textfile]. In fact, [sssad] doesn't save at all on its own.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Re-hello,
I've just figured out that there is an error in one of the patches I've posted,
Here is the memory patch and it's application again,
It's made with native functions and you won't need any external file with it (text file or anything)
Open menu-test.pd for having a sight.
Patco
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
#N canvas 274 215 442 487 10; #X obj 9 12 inlet; #X msg 214 211 addcomma; #X msg 116 170 set; #X obj 116 148 spigot 1; #X msg 123 125 0; #X obj 71 102 t b a b b b; #X msg 159 126 1; #X obj 159 103 r $1-init; #X obj 226 385 ==; #X obj 132 429 spigot; #X obj 132 450 outlet; #X obj 292 216 inlet; #X obj 129 324 list split 1; #X obj 314 47 route clear; #X obj 321 135 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 86 212 list prepend add2; #X obj 129 404 list append; #X obj 86 238 list trim; #X obj 284 252 t b b a; #X obj 129 346 t b a; #X obj 86 271 s $1-msg-in; #X obj 129 300 r $1-msg-out; #N canvas 0 0 454 304 length 0; #X obj 126 70 inlet; #X obj 161 209 + 1; #X obj 81 162 b; #X obj 116 249 f; #X obj 116 276 outlet; #X obj 148 183 1; #X obj 132 211 f 1; #X obj 206 213 0; #X obj 126 104 t a b b; #N canvas 0 0 541 415 drip 0; #X obj 64 206 list split 1; #X obj 64 123 until; #X obj 64 181 list append; #X obj 194 206 bang; #X text 146 90 First store list , then start the loop; #X text 163 118 "until" bangs its output until told to stop by a "bang" to its right inlet.; #X text 182 160 Store the remaining list.; #X text 239 205 third outlet of "split" tells us to stop.; #X obj 64 243 outlet; #X obj 64 57 inlet; #X text 237 44 From list-help.pd; #X obj 143 243 outlet; #X obj 64 86 t b a; #X connect 0 0 8 0; #X connect 0 1 2 1; #X connect 0 2 3 0; #X connect 0 2 11 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 3 0 1 1; #X connect 9 0 12 0; #X connect 12 0 1 0; #X connect 12 1 2 1; #X restore 81 133 pd drip; #X connect 0 0 8 0; #X connect 1 0 6 1; #X connect 2 0 6 0; #X connect 3 0 4 0; #X connect 5 0 6 1; #X connect 6 0 1 0; #X connect 6 0 3 1; #X connect 7 0 3 1; #X connect 8 0 9 0; #X connect 8 1 5 0; #X connect 8 2 7 0; #X connect 9 0 2 0; #X connect 9 1 3 0; #X restore 341 355 pd length; #X obj 328 385 i; #X obj 328 308 loadbang; #X obj 328 411 outlet; #X obj 341 334 r $1-msg-out; #X connect 0 0 5 0; #X connect 0 0 13 0; #X connect 1 0 20 0; #X connect 2 0 20 0; #X connect 3 0 2 0; #X connect 4 0 3 1; #X connect 5 1 15 0; #X connect 5 2 4 0; #X connect 5 3 3 0; #X connect 5 4 1 0; #X connect 6 0 3 1; #X connect 7 0 6 0; #X connect 8 0 9 1; #X connect 9 0 10 0; #X connect 11 0 18 0; #X connect 12 0 19 0; #X connect 12 1 16 1; #X connect 13 0 14 0; #X connect 14 0 2 0; #X connect 15 0 17 0; #X connect 16 0 9 0; #X connect 17 0 20 0; #X connect 18 0 20 0; #X connect 18 2 8 1; #X connect 19 0 16 0; #X connect 19 1 8 0; #X connect 21 0 12 0; #X connect 22 0 23 1; #X connect 23 0 25 0; #X connect 24 0 23 0; #X connect 26 0 22 0;
#N canvas 167 197 586 436 10; #X obj 0 0 cnv 15 80 20 empty $1-menu-cnv cat 30 12 1 8 -233017 -1 0; #X obj 18 0 hsl 60 20 0 127 0 0 $1-menu-sl $1-menu-sl-r dog 2 10 0 8 -166441 -166441 -1 0 1; #X floatatom 1 3 2 1 99 0 - - -; #X obj 302 62 inlet; #X obj 20 300 outlet; #X obj 231 60 r $1-menu; #X msg 200 259 label $1; #X obj 302 88 list trim; #X msg 324 165 clear; #X obj 200 229 symbol; #X obj 200 208 litememory $1; #X msg 362 226 label; #X obj 200 324 s $1-menu-sl-r; #X obj 70 208 i; #X obj 70 154 r $1-menu-sl; #X obj 70 181 t b; #X obj 302 121 route add index clear label; #X obj 412 174 symbol; #X msg 411 229 label $1; #X obj 273 259 list prepend range; #X msg 273 230 0 $1; #X connect 2 0 10 1; #X connect 2 0 13 1; #X connect 3 0 7 0; #X connect 5 0 7 0; #X connect 6 0 12 0; #X connect 7 0 16 0; #X connect 8 0 10 0; #X connect 9 0 6 0; #X connect 10 0 9 0; #X connect 10 1 20 0; #X connect 11 0 12 0; #X connect 13 0 4 0; #X connect 14 0 15 0; #X connect 15 0 13 0; #X connect 16 0 10 0; #X connect 16 1 2 0; #X connect 16 2 8 0; #X connect 16 2 11 0; #X connect 16 3 17 0; #X connect 17 0 18 0; #X connect 18 0 12 0; #X connect 19 0 12 0; #X connect 20 0 19 0; #X coords 0 -1 1 1 80 20 1 0 0;
#N canvas 469 45 478 600 10; #X msg 137 31 add 1 dog , add 2 cat , add 3 test; #X floatatom 73 71 2 0 0 0 - - -; #X msg 74 113 index $1; #X msg 176 75 clear; #X obj 158 229 menu test; #X text 171 57 clear the menu content; #N canvas 0 0 506 356 array 0; #X obj 105 32 r test-msg-in; #X obj 102 121 s test-msg-out; #X msg 107 74 1 dog , 2 cat , 3 test; #X text 235 32 this is the memory; #X connect 0 0 2 0; #X connect 2 0 1 0; #X restore 259 197 pd array; #X obj 212 145 s pd-menu-test.pd; #X text 259 181 menu content is here; #X obj 36 200 s test-menu; #X floatatom 30 134 2 0 0 0 - - -; #X msg 31 163 index $1; #X msg 212 121 menusave; #X text 47 454 just don't forget to associate an array subpatch with the send-receive objects in the same patch , like in this example. ; #X text 167 211 menu <test>; #X text 45 392 creation arguments: menu <name of the menu>; #X text 46 421 with this method you can put several different menus in the same patch; #X floatatom 160 262 5 0 0 0 - - -; #X text 208 100 save the menus content; #X text 150 14 fill the menu; #X text 46 309 When the menu is filled , choose a number and click on the slider; #X connect 0 0 4 0; #X connect 1 0 2 0; #X connect 2 0 4 0; #X connect 3 0 4 0; #X connect 4 0 17 0; #X connect 10 0 11 0; #X connect 11 0 9 0; #X connect 12 0 7 0;
hi patco
i'd like to try your patch. but don't understand where the first one ends and the second one starts. :( it would be nice when you send it as attached file.
thanks
eni
On Jul 5, 2006, at 5:44 AM, patco wrote:
Re-hello,
I've just figured out that there is an error in one of the patches I've posted,
Here is the memory patch and it's application again,
It's made with native functions and you won't need any external file with it (text file or anything)
Open menu-test.pd for having a sight.
Patco
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.#N canvas 274 215 442 487 10; #X obj 9 12 inlet; #X msg 214 211 addcomma; #X msg 116 170 set; #X obj 116 148 spigot 1; #X msg 123 125 0; #X obj 71 102 t b a b b b; #X msg 159 126 1; #X obj 159 103 r $1-init; #X obj 226 385 ==; #X obj 132 429 spigot; #X obj 132 450 outlet; #X obj 292 216 inlet; #X obj 129 324 list split 1; #X obj 314 47 route clear; #X obj 321 135 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 86 212 list prepend add2; #X obj 129 404 list append; #X obj 86 238 list trim; #X obj 284 252 t b b a; #X obj 129 346 t b a; #X obj 86 271 s $1-msg-in; #X obj 129 300 r $1-msg-out; #N canvas 0 0 454 304 length 0; #X obj 126 70 inlet; #X obj 161 209 + 1; #X obj 81 162 b; #X obj 116 249 f; #X obj 116 276 outlet; #X obj 148 183 1; #X obj 132 211 f 1; #X obj 206 213 0; #X obj 126 104 t a b b; #N canvas 0 0 541 415 drip 0; #X obj 64 206 list split 1; #X obj 64 123 until; #X obj 64 181 list append; #X obj 194 206 bang; #X text 146 90 First store list , then start the loop; #X text 163 118 "until" bangs its output until told to stop by a "bang" to its right inlet.; #X text 182 160 Store the remaining list.; #X text 239 205 third outlet of "split" tells us to stop.; #X obj 64 243 outlet; #X obj 64 57 inlet; #X text 237 44 From list-help.pd; #X obj 143 243 outlet; #X obj 64 86 t b a; #X connect 0 0 8 0; #X connect 0 1 2 1; #X connect 0 2 3 0; #X connect 0 2 11 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 3 0 1 1; #X connect 9 0 12 0; #X connect 12 0 1 0; #X connect 12 1 2 1; #X restore 81 133 pd drip; #X connect 0 0 8 0; #X connect 1 0 6 1; #X connect 2 0 6 0; #X connect 3 0 4 0; #X connect 5 0 6 1; #X connect 6 0 1 0; #X connect 6 0 3 1; #X connect 7 0 3 1; #X connect 8 0 9 0; #X connect 8 1 5 0; #X connect 8 2 7 0; #X connect 9 0 2 0; #X connect 9 1 3 0; #X restore 341 355 pd length; #X obj 328 385 i; #X obj 328 308 loadbang; #X obj 328 411 outlet; #X obj 341 334 r $1-msg-out; #X connect 0 0 5 0; #X connect 0 0 13 0; #X connect 1 0 20 0; #X connect 2 0 20 0; #X connect 3 0 2 0; #X connect 4 0 3 1; #X connect 5 1 15 0; #X connect 5 2 4 0; #X connect 5 3 3 0; #X connect 5 4 1 0; #X connect 6 0 3 1; #X connect 7 0 6 0; #X connect 8 0 9 1; #X connect 9 0 10 0; #X connect 11 0 18 0; #X connect 12 0 19 0; #X connect 12 1 16 1; #X connect 13 0 14 0; #X connect 14 0 2 0; #X connect 15 0 17 0; #X connect 16 0 9 0; #X connect 17 0 20 0; #X connect 18 0 20 0; #X connect 18 2 8 1; #X connect 19 0 16 0; #X connect 19 1 8 0; #X connect 21 0 12 0; #X connect 22 0 23 1; #X connect 23 0 25 0; #X connect 24 0 23 0; #X connect 26 0 22 0; #N canvas 167 197 586 436 10; #X obj 0 0 cnv 15 80 20 empty $1-menu-cnv cat 30 12 1 8 -233017 -1 0; #X obj 18 0 hsl 60 20 0 127 0 0 $1-menu-sl $1-menu-sl-r dog 2 10 0 8 -166441 -166441 -1 0 1; #X floatatom 1 3 2 1 99 0 - - -; #X obj 302 62 inlet; #X obj 20 300 outlet; #X obj 231 60 r $1-menu; #X msg 200 259 label $1; #X obj 302 88 list trim; #X msg 324 165 clear; #X obj 200 229 symbol; #X obj 200 208 litememory $1; #X msg 362 226 label; #X obj 200 324 s $1-menu-sl-r; #X obj 70 208 i; #X obj 70 154 r $1-menu-sl; #X obj 70 181 t b; #X obj 302 121 route add index clear label; #X obj 412 174 symbol; #X msg 411 229 label $1; #X obj 273 259 list prepend range; #X msg 273 230 0 $1; #X connect 2 0 10 1; #X connect 2 0 13 1; #X connect 3 0 7 0; #X connect 5 0 7 0; #X connect 6 0 12 0; #X connect 7 0 16 0; #X connect 8 0 10 0; #X connect 9 0 6 0; #X connect 10 0 9 0; #X connect 10 1 20 0; #X connect 11 0 12 0; #X connect 13 0 4 0; #X connect 14 0 15 0; #X connect 15 0 13 0; #X connect 16 0 10 0; #X connect 16 1 2 0; #X connect 16 2 8 0; #X connect 16 2 11 0; #X connect 16 3 17 0; #X connect 17 0 18 0; #X connect 18 0 12 0; #X connect 19 0 12 0; #X connect 20 0 19 0; #X coords 0 -1 1 1 80 20 1 0 0; #N canvas 469 45 478 600 10; #X msg 137 31 add 1 dog , add 2 cat , add 3 test; #X floatatom 73 71 2 0 0 0 - - -; #X msg 74 113 index $1; #X msg 176 75 clear; #X obj 158 229 menu test; #X text 171 57 clear the menu content; #N canvas 0 0 506 356 array 0; #X obj 105 32 r test-msg-in; #X obj 102 121 s test-msg-out; #X msg 107 74 1 dog , 2 cat , 3 test; #X text 235 32 this is the memory; #X connect 0 0 2 0; #X connect 2 0 1 0; #X restore 259 197 pd array; #X obj 212 145 s pd-menu-test.pd; #X text 259 181 menu content is here; #X obj 36 200 s test-menu; #X floatatom 30 134 2 0 0 0 - - -; #X msg 31 163 index $1; #X msg 212 121 menusave; #X text 47 454 just don't forget to associate an array subpatch with the send-receive objects in the same patch , like in this example. ; #X text 167 211 menu <test>; #X text 45 392 creation arguments: menu <name of the menu>; #X text 46 421 with this method you can put several different menus in the same patch; #X floatatom 160 262 5 0 0 0 - - -; #X text 208 100 save the menus content; #X text 150 14 fill the menu; #X text 46 309 When the menu is filled , choose a number and click on the slider; #X connect 0 0 4 0; #X connect 1 0 2 0; #X connect 2 0 4 0; #X connect 3 0 4 0; #X connect 4 0 17 0; #X connect 10 0 11 0; #X connect 11 0 9 0; #X connect 12 0 7 0; _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi eni,
Enrique Erne pd@mild.ch a écrit : hi patco
i'd like to try your patch. but don't understand where the first one ends and the second one starts. :( it would be nice when you send it as attached file.
That's curious because the patches was sent as attached files, I've archived the files for avoiding this problem occurs anymore.
Patco.
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
Hallo, patco hat gesagt: // patco wrote:
Here is the memory patch and it's application again,
It's made with native functions and you won't need any external file with it (text file or anything)
You're slowly approaching a clone of [sssad] ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hello,
Maybe the difference is that [sssad] is in need of a textfile, I don't think I will do any improvement because [litememory] would indeed become an unusefull clone of [sssad]. I was in need of this little memory for making particular applications where textfiles would make life more complicated, I hope these applications will be ready soon without the need of any external library.
If anyone wants to have a sight of the application I am trying to make with, I put an archive with all the work in it.
But don't expect to see it working, it's not terminated yet.
Patco.
Frank Barknecht fbar@footils.org a écrit : Hallo, patco hat gesagt: // patco wrote:
Here is the memory patch and it's application again,
It's made with native functions and you won't need any external file with it (text file or anything)
You're slowly approaching a clone of [sssad] ;)
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
patco wrote:
I was in need of this little memory for making particular applications where textfiles would make life more complicated, I hope these applications will be ready soon without the need of any external library.
just to make this clear: [textfile] is built into pd-core, so you don't need any external library in order to access such a textfile.
(there are however external libraries that provide access to textfiles)
mfga.sdr IOhannes
IOhannes m zmoelnig zmoelnig@iem.at a écrit : patco wrote:
I was in need of this little memory for making particular applications where textfiles would make life more complicated, I hope these applications will be ready soon without the need of any external library.
just to make this clear: [textfile] is built into pd-core, so you don't need any external library in order to access such a textfile.
(there are however external libraries that provide access to textfiles)
mfga.sdr IOhannes Sorry to not have been clear enough, let me try to explain my point deeper.
I am working on patches that are dynamically creating and deleting GOP abstractions for saving memory and screen room.
These GOP abstractions are all differently configured and requires a memorisation of parameters (not values).
If after the creation process of an abstraction a text file is implemented for memorizing the different parameters (not the values of the parameters):
1° it's far more tricky to manipulate both the text file and the created abstraction with using the native function [textfile]
2° the folder of the application where abstractions are dynamically created (and erased) would be overflooded by text files (and those text files would become unusable if the project in the application is cancelled), because with the native object [textfile] it's very tricky to erase a few data without erasing everything in a text file.
I hope I've demonstrated clearly enough how it might be important to have a memory inside an abstraction.
I might use a wrong process of dynamical creation, but for the moment I've never saw any PD application that is able to do many things without filling all the screen and sucking a big load of the computer memory just for displaying the graphical interface.
Patco.
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
patco wrote:
I hope I've demonstrated clearly enough how it might be important to have a memory inside an abstraction.
yeah, perfectly.
there are certainly situations where data ought to be stored in the patch (after all, a patch IS both code and data; this is one of the core differences between pd and max (although you can store data in max patches too)).
i just wanted to keep anybody from thinking that [textfile] is only available via external libraries and that it should be avoided in general if you want to depend on as little external ressources as possible.
mfg.asdr. IOhannes
Hallo, patco hat gesagt: // patco wrote:
Maybe the difference is that [sssad] is in need of a textfile,
[sssad] isn't in need of a textfile. It is agnostic in regard to how you want to save the state in the end. Attched patch shows, how to use it with message boxes for this.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sat, Jul 08, 2006 at 11:30:11AM +0200, Frank Barknecht wrote:
Hallo, patco hat gesagt: // patco wrote:
Maybe the difference is that [sssad] is in need of a textfile,
[sssad] isn't in need of a textfile. It is agnostic in regard to how you want to save the state in the end. Attched patch shows, how to use it with message boxes for this.
Frank, All,
This kicks butt. So I have made a GOP abstraction like [sssad/panel] which saves to a subpatch called [pd datastore]. For folks who are feeling too sssad about saving to text files, they can now opt to save to messagebox in a subpatch instead. Check it out:
http://mccormick.cx/viewcvs/*checkout*/s-abstractions/sssad/datastore.pd http://mccormick.cx/viewcvs/*checkout*/s-abstractions/sssad/datastore-help.p...
Best regards,
Chris.
PS I found the TipsAndTricks page really useful for the internal message stuff.
chris@mccormick.cx http://mccormick.cx
padawan12 wrote:
Arrays are not the best thing to use for data persistence. Messages constructed using "set" and then textfiles are preferable.
stupid me, but what makes arrays less good than "set" and textfiles? i don't see a real difference between the two (well, you can save non-numeric values in textfiles which you cannot do with arrays (at least not with reasonable effort) and raw "array-files" might be harder to read by a human than textfiles. and you might need to put quite some logic into your loading abstraction to distribute the data to various destinations (and vice-versa when it comes to saving).
but generally there is no realy reason to make arrays less preferable to textfiles.
mfga.drta IOhannes
-
Chris McCormick -
Christopher Charles -
Chuckk Hubbard -
Enrique Erne -
Frank Barknecht -
IOhannes m zmoelnig -
João Miguel Pais -
padawan12 -
patco -
sokratesla