[PD] help! my patch breaks pd!

Krzysztof Czaja czaja at chopin.edu.pl
Wed Aug 22 14:49:40 CEST 2001


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

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


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

More information about the Pd-list mailing list