[PD] help! my patch breaks pd!

[Miller Puckette]

> 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 call that "instantiating" the abstraction; not sure if that's the best
term.

> 
> 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
> 

Yes, puzzling.  Have you tried it on a different machine?  If you'd like, send
a zip archive with all the files in it and I'll see if I can recreate the
problem.  If you've got 256M I just don't see how your patch could be running
out of memory...  Although Krzysztof has shown me wrong about how Pd is using
memory allocation...!

cheers
Miller

> 
> 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
> 

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