Date: Thu, 03 Jul 2008 09:37:05 +0200 From: Atte Andr? Jensen atte.jensen@gmail.com Subject: Re: [PD] best way to do 1/x To: pd-list@iem.at Message-ID: 486C81A1.9050001@gmail.com Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Frank Barknecht wrote:
Yes, it is. ;)
But slightly more tricky is that send/recieve must have the same "problems", but may be more difficult to spot.
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. 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).
Now that I think about it, wouldn't [loadbang]'s in abstractions necessarily have to go before [loadbang]'s elsewhere in the parent patch, to initialize the internal state of the abstraction before any data can be sent to it? And if this is the case, would this "inside-out" loadbang order extend to [pd subpatch]'s too? Anyway, if this were the case it would still not be something to rely upon too heavily.
BTW, since you mentioned it I believe [send] and [receive] should be included in "depth-first" control dataflow chains, just like regular connections (it would be a serious design flaw if this weren't the case, I think -- but you're right, it can be harder to track down, and harder still if the send and receive symbols live inside graphical objects...). As a fun experiment, see what happens if you make a control connection loop (also see what happens with an audio loop). It's good to be aware of what happens during various kinds of errors.
Matt
Matt Barber wrote:
BTW, since you mentioned it I believe [send] and [receive] should be included in "depth-first" control dataflow chains, just like regular
well, what makes you think that [s]/[r] are not?
internally send/receive _are_ indeed regular connections, they are just invisible (and thus do not have the constraints of the more "physical" connections that cannot (e.g.) cross the patch-boundaries.
and of course since you don't see the connections and cannot interact with them) there is no way to insert a execution order forcer, like [trigger].
fgmasdr IOhannes
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
-
IOhannes m zmoelnig -
Mathieu Bouchard -
Matt Barber