[PD] Loadbang behavior, WAS: best way to do 1/x
matju at artengine.ca
Thu Jul 3 18:17:57 CEST 2008
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
> 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,
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
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
[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
More information about the Pd-list