[PD] bang of loadbang

Frank Barknecht fbar at footils.org
Mon Jun 27 12:01:28 CEST 2005


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




More information about the Pd-list mailing list