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

[Matt Barber]

> Date: Thu, 03 Jul 2008 09:37:05 +0200
> From: Atte Andr? Jensen <atte.jensen at gmail.com>
> Subject: Re: [PD] best way to do 1/x
> To: pd-list at iem.at
> Message-ID: <486C81A1.9050001 at 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