[PD] help! my patch breaks pd!

[Greg Rippin]

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 at nyu.edu
www.nyu.edu

-------------- next part --------------
#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;