hi Ben, Iohannes,
(even if usually avoiding dynamic creation, but still...) I have some crazy thoughts:
IOhannes zmoelnig wrote: ...
because it would take you to hell.
do you mean max, with its 'newex' -> [thispatcher]? It works...
the main problem is (as i see it) that you really do not know when to trigger the loadbang: immediately after its creation ? (this would be
...
after the patch is finished ???? in true dynamic patch-creation, who
theoretically, it seems to be the only logical place to put in the loadbang call. The main problem is, however, that loadbangs are dealt with in Pd in a somewhat ad hoc fashion -- there is no unified scheme yet. So, in practice, there is no good place to put this call, without major code redesign, at least I do not see it (as usual).
knows ? if you are just dynamically loading abstractions with nested [loadbang]s, the problem of not being able to connect the abstraction's outlet to something before the loadbang fires reappears...
why this is a major problem -- why this should make firing of loadbangs inappropriate? (dangerous, misleading?)
the major difference between dynamic patch-creation and loading a patch is, that, when loading (from a file) you know your parent patch before you have to initiate the child, while on dynamic creation the parent you are in "edit"-mode, so your parent is not finished yet (normally, of
well... dynamic creation does not cause switching to edit-mode... (besides, this is yet another case of a 'dirty-flag' bug)
Krzysztof