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