Hallo,
(better include pd-list in CC)
jmmmp hat gesagt: // jmmmp wrote:
It should bang again, and it think it always did, at least it does on my machines.
then I think something is not right here: I just made a test, an
abstraction with loadbang connected to a print and outlet objects. in the
parent the outlet of the abstraction is connected to a toggle. the print
inside the abstraction accuses the bang everytime I change the parameters
in the parent (which is actually the same as creating the abstraction
again), but the toggle in the parent doesn't change.
Ah, yes, interestingly the loadbang is not carried through to the outside world. I don't know if this is desireable or not. Anyways you can fake a loadbang by sending the message "loadbang" to a receiver called "pd-NAME_OF_SUBPATCH" or "pd-NAME_OF_ABSTRACTION.pd" as in attached patches. (Main patch is lb-test.pd)
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
Frank Barknecht wrote:
Hallo,
(better include pd-list in CC)
jmmmp hat gesagt: // jmmmp wrote:
Ah, yes, interestingly the loadbang is not carried through to the outside world. I don't know if this is desireable or not. Anyways you
this has been discussed many times on the list (just search the archives for loadbang and dynamic patching (yes, creating or renaming an object can be considered as dynamic patching) and i still think that this is not a bug (though not a feature either)
so [loadbang] bangs at patch loading time (as opposed to patch creating time). probably there is a need for [createbang] that bangs more often.
in the meanwhile, i think frank's suggestion is ok:
can fake a loadbang by sending the message "loadbang" to a receiver called "pd-NAME_OF_SUBPATCH" or "pd-NAME_OF_ABSTRACTION.pd" as in attached patches. (Main patch is lb-test.pd)
mfg.as.dr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Ah, yes, interestingly the loadbang is not carried through to the outside world. I don't know if this is desireable or not. Anyways you
this has been discussed many times on the list (just search the archives for loadbang and dynamic patching (yes, creating or renaming an object can be considered as dynamic patching) and i still think that this is not a bug (though not a feature either)
I don't think, this particular problem was discussed many times, if at all. The loadbang is done just fine inside the abstraction, if you change arguments, however it does not pass through to the outlet. With dynamic patches, you don't get a loadbang at all, not inside and not outside the abstraction. This is a different issue, as there's just no loadbang generated, whereas in the first case, there is a bang, but its progression is stopped at the outlet.
so [loadbang] bangs at patch loading time (as opposed to patch creating time).
Well, not if you create abstractions manually, which will send a lodbang and it damn sure should do so. ;)
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Ah, yes, interestingly the loadbang is not carried through to the outside world. I don't know if this is desireable or not. Anyways you
this has been discussed many times on the list (just search the archives for loadbang and dynamic patching (yes, creating or renaming an object can be considered as dynamic patching) and i still think that this is not a bug (though not a feature either)
I don't think, this particular problem was discussed many times, if at all. The loadbang is done just fine inside the abstraction, if you change arguments, however it does not pass through to the outlet. With dynamic patches, you don't get a loadbang at all, not inside and not outside the abstraction. This is a different issue, as there's just no loadbang generated, whereas in the first case, there is a bang, but its progression is stopped at the outlet.
this is really interesting. i didn't know that and i thought the 2 cases would behave exactly the same (i obviously haven't made any tests to prove it) the problem with dynamic patching is that the outlets are not yet defined so a loadbang distributed to them would go into the void (ok, _this_ has been discussed); but there would be no problems just for internal initialization, so it could (should?) behave exactly like jmmmp described their problem.
so [loadbang] bangs at patch loading time (as opposed to patch creating time).
Well, not if you create abstractions manually, which will send a lodbang and it damn sure should do so. ;)
either it behaves the _same_ as dynamic patching or it doesn't stop halfway.
mfg.asd.r IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
this is really interesting. i didn't know that and i thought the 2 cases would behave exactly the same (i obviously haven't made any tests to prove it) the problem with dynamic patching is that the outlets are not yet defined so a loadbang distributed to them would go into the void (ok, _this_ has been discussed); but there would be no problems just for internal initialization, so it could (should?) behave exactly like jmmmp described their problem.
When I use dynamic patching I often connect a little "once" structure using [spigot 1] and a [t b a] cross-connected to that inside the abstraction which is dynamically created. The [t b a] then intercepts the first value coming in through an inlet or some receiver value and uses it to initialize things once, then closes the spigot. If dynamically created abstractions would use the loadbang internally as manually created ones do, I would not need to do that or send a [loadbang( message.
I think, that having loadbangs bang on creation/change of abstractions (manually) generally is important, because it makes abstractions behave more like builtin objects. An example could be an extended "float" object, lets call it [rrad.float] ;) that accepts an argument like [rrad.float 12]
If I change the 12 to 20, then the stored float should be changed as well and maybe do some initialization through a loadbang inside. This is analogous to the real [float]. However the real one does not immediatly send a new value, if it is recreated using a different value. To keep this analogy the outlet of [rrad.float] should also not send a new value through its outlet after it gets recreated - provided it could do so.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
If I change the 12 to 20, then the stored float should be changed as well and maybe do some initialization through a loadbang inside. This is analogous to the real [float]. However the real one does not immediatly send a new value, if it is recreated using a different value. To keep this analogy the outlet of [rrad.float] should also not send a new value through its outlet after it gets recreated - provided it could do so.
the only question remaining (for me) is, why does this not work for abstractions that are created via dynamic patching. what is the difference between
[obj 100 100 rrad.float 12( | [s pd-bla]
and creating an object [rrad.float 12] in the "bla" subpatch ??
mfg.adsr. IOhannes
Ciao
can fake a loadbang by sending the message "loadbang" to a receiver called "pd-NAME_OF_SUBPATCH" or "pd-NAME_OF_ABSTRACTION.pd" as in attached patches. (Main patch is lb-test.pd)
this feature I didn't know. is it documented anywhere? did I read the
manual too fast?
that reminds me of another point: is there any manual or document with the
possible messages that can be sent directly to pd? the .htm file with the
object description is quite useful (thanks whoever did it), but for a
non-programmer, such possibilities are still unknown.
-
Frank Barknecht -
IOhannes m zmoelnig -
jmmmp