An annoying but effective temporary fix is to give each object that you create a unique name, and have a [receive] by the same name inside the created patch. The last step in creating an object, then, is to send a bang to the name of the object. Crude, but it approximates a loadbang.
Greg
-- Greg Rippin, Graduate Assistant Music Technology Program New York University 35 West 4th Street, Suite 777 New York, NY 10012
phone 212-998-5422 fax 212-995-4043 musictechgrad.info@nyu.edu www.nyu.edu
----- Original Message ----- From: Krzysztof Czaja czaja@chopin.edu.pl Date: Tuesday, July 16, 2002 5:29 pm Subject: Re: [PD] dynamic object creation
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