[PD] Segmented Patch Chords? PVar / PV?

Roman Haefeli reduzierer at yahoo.de
Tue Feb 14 21:05:40 CET 2006

thnx to matju and item for your answers

it's very good to know all this info. in fact i already made
installations, where a pd-patch is running during the whole day
(although i believe it is not an issue in this specific case).

i'm still not quite sure if i undesrstand it correctly. are only
symbols like array-names, [send]s and [receive]s, [throw~] and [catch~]
etc stored in pd's symbol-table (which i assume)? or does also sending
a lot of messages and using [route symbol] lead to a pollution of the

if the first case is true, there are maybe some ways to avoid too much
pollution. in case of netpd for example it happens that often a bunch
of patches are open and each of them uses a lot of
send/receive-symbols. now, if i understand it right, using:

[r mysynth]
[route freq amplitude]

causes less pollution than something like this:

[r mysynth-freq]

[r mysynth-amplitude]

is that right?
is it also better to use short symbols or doesn't that matter?


On Tue, 14 Feb 2006 07:32:58 -0500 (EST)
Mathieu Bouchard <matju at artengine.ca> wrote:

> On Tue, 14 Feb 2006, Roman Haefeli wrote:
> > "Mathieu Bouchard" <matju at artengine.ca> wrote:
> > > > $0-send/receive: what would be the difference to a NOT-fake-mechanism?
> > > Avoiding pollution of the symbol-table?
> > this topic has been mentioned already a few times on this list, but suddenly i
> > still don't know what this means exactly. does pollution mean, that the
> > symbol-table uses a lot of ram? does that have any bad effects on performance?
> > is there a good way to avoid pollution (i mean when patching) ?
> Pd starts up with a fixed-size symbol-table. This is a big array of
> symbols. If the table becomes full (or even just crowded) there are more
> and more symbols that share the same cell in the symbol-table by chaining
> one symbol to another. Long chains of symbols are slow. If you use many
> symbols, the quick fix is to increase the size of the table but to do 
> that you need to recompile pd.
> Most of the problem of having many symbols comes from the fact that most
> symbols have two parts, because they're made like $0-foo where $0 is some
> integer. There's no quick escape from that. Pd needs a new atom type for
> local symbols. When it gets it, all externals would have to be updated in 
> order to support it.
> The other main cause of symbol pollution is that pd doesn't have text
> strings. Strings can be deallocated, while symbols are æternal, that is,
> until you quit pd. If you use pd for heavy string processing in an art
> installation, make sure you do scheduled shutdowns in order to prevent
> swapping, thrashing and crashing; make tests and extrapolations to figure 
> out when it would have used all of your RAM, etc.
>  _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
> | Freelance Digital Arts Engineer, Montréal QC Canada

More information about the Pd-list mailing list