[PD] Loadbang behavior, WAS: best way to do 1/x

[Mathieu Bouchard]

On Thu, 3 Jul 2008, Matt Barber wrote:

> In my patches I sometimes like to have one global [loadbang] which
> lives in a subpatch called something like [pd init], with one big
> [trigger] and a bunch of [send]'s.  That way I can control exactly
> what order things get initialized and I never have to guess or be
> surprised by the order of loadbangs in several other subpatches.

Yes, this is something that you may have to do. You only have to do this 
when you have to [loadbang] a hot inlet, but when you do have to, it's a 
mess. This is why I added the "init-message" in GridFlow: [hello, world] 
is like [loadbang]ing a "world" message into [hello]. This greatly reduces 
the number of loadbangs (or of creation arguments that count as such), and 
most of all, reduces the amount of scheduling that you have to do on 
[loadbang].

> However, just like with any message, if you are sending the same thing
> in several unrelated directions which all eventually dead-end into a
> "cold" inlet, you don't need to worry about the order (as much,
> anyway).

As long as the cold inlet involved in what any other [loadbang] does... I 
mean a cold inlet's contents get involved in what a hot inlet does, and if 
such a hot inlet is triggered through a [loadbang] (perhaps indirectly) 
then order of the loadbangs matters.

> Now that I think about it, wouldn't [loadbang]'s in abstractions 
> necessarily have to go before [loadbang]'s elsewhere in the parent 
> patch,

Yes, it does. It's "topologically sorted"... aka inside-out like you said.

> BTW, since you mentioned it I believe [send] and [receive] should be
> included in "depth-first" control dataflow chains, just like regular
> connections

[send] and [receive] are depth-first. To do breadth-first you need use 
[delay] or [pipe] or any other clock-based object.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec