Hello all,
I have a patch which creates an abstraction dynamically (via message) but when the abstraction is loaded it does not receive loadbang events. I would think the behavior for adding a dynamic object via message and adding one by hand would be the same. If I press space after my abstraction name then it reloads, including loadbangs. Its not problem to fix but I was wondering weather it makes sense to make that change so that when you create an abstraction dynamically it hits its loadbangs.
Anyhow see any reasons why this would not be a good idea?
Thanks! Ben
B. Bogart
Ben Bogart - FMPM/F1999 wrote:
Hello all,
hi!
Anyhow see any reasons why this would not be a good idea?
because it would take you to hell. 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 the same as it is now, since you would have no chance to connect anything to the [loadbang] and so the trigger would be void). after you connected something to the [loadbang] ??? why ? actually the [loadbang] does not know about anything connected, so who will have to keep the track ? what if you want to connect more than one objects to the loadbang ? (yes, i know of the [t b b], but maybe not all of you use it all the time) after the patch is finished ???? in true dynamic patch-creation, who 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...
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 course, it can be done, but who knows ?)
i have done quite a lot of dynamic patches, and i have dearly wished the loadbang to work inside dynamically loaded abstractions. on having a closer thought i just didn't find a way of doing it properly.
so the easiest thing is, to add an "init"-inlet to your abstraction and trigger it from outside.
mfg.ds.dr IOhannes
Thanks! Ben
B. Bogart
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
hi !
...
because it would take you to hell.
do you mean max, with its 'newex' -> [thispatcher]? It works...
i have to admit, i do not have any (real) experience with max
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?)
no, i just think, it doesn't really do what you want it to do. if i have an abstraction with a [loadbang], i can use it for 2 (and a lot of other) reasons: (now saying very obvious things)
- to initialize objects inside the abstraction (including
sub-abstractions): the loadbang could fire, as soon as the abstraction is instantiated 2. to initialize the parent-patch (via an [outlet]): then the loadbang has to fire after the abstraction is connected to something. in my special cases, this turned out to happen quite often. and i haven't seen a simple solution for this.
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)
well, this was meant in a metaphoric way. although you are not switching to edit-mode, you do edit the patch and thus pd doesn't know, when editing is finished.
mfg.ds.f IOhannes
-
Ben Bogart - FMPM/F1999 -
IOhannes zmoelnig -
Krzysztof Czaja