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