[PD] self-modifying and dynamic patching

Frank Barknecht fbar at footils.org
Thu Mar 12 17:43:11 CET 2009


Hallo,
Phil Stone hat gesagt: // Phil Stone wrote:

> Good point; I assume you're going to emphasize the pitfalls of dynamic  
> patching while you're at it, Derek?  I have a habit of opening up  
> patches to see how they work, and if I can't read them because they're  
> too messy, I'll move stuff around.  This is fine, unless it's a dynamic  
> patch and I hit "ctrl-s" without thinking.  D'oh!  The initial state of  
> a dynamic patch is critical to its correct function, and one has to  
> think very carefully before saving changes.  I think I'm going to  
> develop the habit of putting a large warning comment on any  
> self-modifying patch.

With certain clean patching habits it's not that bad. For example the original
nqpoly4 was rather messy because it did the dynamic patching in the abstraction
itself, used namcanvas for it and thus relied on a certain initial state. 

What I changed was to remove namcanvas, do the dynamic patching inside of a
subpatch and started with clearing that patch from a loadbang. 

A loadbanged [; pd-subpatch clear( IMO is mandatory for dynamic patching in
abstractions. Even if it's saved with old content that will be removed on the
next load.

Another use for dynamic patching is automatically creating parts of static
patches.  For example my piece "Frost" on the GOSUB10 netlabel release uses 60
resonant bandpass filters driven by noise bursts. Of course I didn't patch all
of these manually and changed their arguments, instead I used dynamic patching
to generate the filter bank once, which then was saved into a static patch.

In that use case, one should not use a loadbang'd clear of course. ;)

To add another example: I use dynamic patching in the list-abs-intro.pd patch
to generate a list of all list-abs in the [list]-abs collection.

Ciao
-- 
Frank




More information about the Pd-list mailing list