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.
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41