Krzysztof and others,
Please excuse my confusion of the terminology. I'm a musician first and a programmer second; both my training and my experience with more complex computer matters are both lacking (which, I am sure, is not helping me solve this problem at all).
The abstract definition is reused, called repeatedly with different initialization arguments each time. I supposed the correct term would therefore be "instances". As I said, each instance has two inlets, two outlets, and two [r ] objects. One of the [r ] objects is the same in each instance (which receives a global reset command). The other [r ] is the same in every group of 13 instances, as defined by the initialization arguments.
I've attached a copy of the abstraction in question. I'm only (only!?) running 256 Mb, and I'm starting to think that this may be the problem. Incidentally, the resource monitor I've been using is the one that came with Windows 98. Can anyone suggest a better utility for this?
Here's the detail that's been puzzling me throughout the day: if I rebuild the patch, it works just fine. It's only when I save it, close it, and try to reopen it that the problems occur.
Thanks all for your help! Greg
Krzysztof Czaja wrote:
hi,
not really shure what you mean by _calling_ an abstraction. Reusing abstraction definition only (a .pd file), which is more like macro expansion (let me talk in a procedural way), or reusing program resources, as if calling a routine? The later would mean passing a message to the _same_ place in a patch. But the same inlet or receive as created in an abstraction definition is _not_ the same place if used in two different instances of this abstraction.
The -verbose printout suggests all 2197 copies are created (either dynamically with 'obj' message, or statically while reading objects from a parent patchfile). In Pd you always get a separate copy of each abstraction instance, thus the full object creation is repeated 2197 times -- all steps, including loading from a file and allocating memory.
Each copy of an empty abstraction takes a little over 600 bytes, and 600*13**3 == 1.3Mb. Putting a simple object, like inlet or receive, into a patch increases the per-instance amount by about 100 bytes (connections take much less). Assuming your abstraction has 8 i/o objects and ~10 simple objects doing the real job, this abstraction uses ~4 times the empty abstraction memory size. But still 5Mb is nothing nowadays, so the only possible reason I know of is memory _fragmentation_.
Krzysztof
(ok, since I was only guessing, the above is not very helpful; perhaps you could attach this small abstraction -- not the multi-thousand-line main patch of course).
Greg Rippin wrote: ...
Thanks Miller for the suggestions. I tried loading the parent patch with an empty abstraction in place of the one that is called 2197 times (as mentioned, this repeatedly called abstraction is very small, but has two inlets, two outlets, and four receive objects) and the parent patch loaded fine. I noticed while trying to load the original parent patch (with the repeated abstraction in place) with the -verbose flag, that the parent pd window scrolls as if it's loading many of the instances being called (trying and failing to find the .dll, finding the .pd) for about fifteen seconds before pd dies.
...
-- Greg Rippin, Graduate Assistant Music Technology Program New York University 35 West 4th Street, Suite 777 New York, NY 10012
phone 212-998-5422 fax 212-995-4043 musictechgrad.info@nyu.edu www.nyu.edu
#N canvas -46 14 782 534 12; #X obj 258 370 /; #X obj -112 271 r reset; #X obj 32 173 inlet; #X obj 13 504 outlet; #X obj 127 504 outlet; #X obj 56 405 f 0; #X msg 262 443 bang; #X obj 269 329 r $1total; #X obj 166 451 * 100; #X obj 121 406 f 0; #X obj -112 301 delay 50; #X obj 177 284 + 1; #X obj 115 284 float 0; #X obj -111 330 f -1; #X obj 371 175 inlet; #X obj 373 227 pipe 50; #X obj 373 203 - 1; #X text -69 -126 inputs a bang representing a categorized event (specific harmonic sequence); #X text -73 -88 outputs total number of events that match that category ; #X text -71 -75 outputs probability of that category of event occuring ; #X text -72 -57 e.g. if the analysis algorithm sees a two-five-one progression , a bang is sent to the "one" probcalc module inside the "fiveone" harmanalmod. This probcalc keeps a running total of bangs it recieves. It also inputs the total number of two-five-xxx sequences that have occured. It divides the total number by the local count , yielding the probability that , when the sequence two-five occurs , the next interval will be a one.; #X text 75 -151 probcalc abstraction; #X text -161 234 reset function; #X text -189 247 resets counter to zero; #X text 10 147 bang input; #X text 126 259 counter; #X text 327 122 load function; #X text 249 137 sets counter to number from table; #X text 251 149 stored in text file; #X text 231 302 total input from parent harmonanalmod; #X text -25 525 number counted; #X text 113 524 probability; #X connect 0 0 8 0; #X connect 1 0 10 0; #X connect 2 0 12 0; #X connect 5 0 3 0; #X connect 6 0 9 0; #X connect 7 0 0 1; #X connect 7 0 6 0; #X connect 8 0 4 0; #X connect 9 0 0 0; #X connect 10 0 13 0; #X connect 11 0 5 0; #X connect 11 0 9 0; #X connect 11 0 12 1; #X connect 12 0 11 0; #X connect 13 0 12 0; #X connect 14 0 16 0; #X connect 15 0 12 0; #X connect 16 0 15 0;