[PD] questions about [send]/[receive]

i go bananas hard.off at gmail.com
Tue Jul 14 07:35:02 CEST 2015

>when 2 different [send A]'s go to the same [receive A] will there be used
a "first-in first-out" procedure?

yes, always.

(unless you deliberately use something such as a [pipe] or [delay] object
in between, of course)

>[send]/[receive]'s inside a subpatch are they handled before
[send]/[receive]'s which 'cross the border' of the subpatch?

no.  the subpatch will not have any impact on the order of execution.

In general, it is bad practice to use a single send going to multiple
receives - the order in which they are received should be considered
undefined.  You should avoid doing that if at all possible.

But in some cases, it is useful, such as sending the global BPM to
different parts of your patch. In that case, you just have to be very
careful that the patch doesn't depend on the order in which the different
receives are triggered.

On Tue, Jul 14, 2015 at 6:07 AM, Peter P. <peterparker at fastmail.com> wrote:

> * rolfm at dds.nl <rolfm at dds.nl> [2015-07-13 16:40]:
> >
> > hi list,
> >
> > to not make a maze of a complicated patch
> > i use quite often send/receive objects inside the patch.
> >
> > triggered by the recent thread about execution order and depth-first,
> > i'm starting to doubt the above mentioned habit.
> >
> > in an much older thread it is said that:
> >  apart from the "right to left" rule for outlets (and inlets?)
> > and the "depth first" rule,
> > execution order in Pd is not defined.
> >
> > does it mean that there's nothing to say/know about send/receive's?
> http://puredata.info/docs/tutorials/PdForMaxUsers#always-use-the-trigger-object
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150714/2eda8982/attachment.html>

More information about the Pd-list mailing list