[PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?

[Frank Barknecht]

Hi Matteo,

On Sun, Apr 18, 2010 at 12:06:57PM +0200, Matteo Sisti Sette wrote:
> If the only way to force execution order is by actually creating a
> "wired" path with subpatches, then it seems to me it is useless for
> [s~]s and [r~]s because if you can sort them in a wired way, then
> you can just replace them by wires, so you didn't need them in the
> first place.

As I wrote, for "simple" connections it's not useful, but as soon as you
do "bigger" calculations where order matters, it's a technique you need
to know. Also s~/r~ are often used where direct connections are
inconvenient, for example if you want to pass the target name by
argument or if you would have a large number of connections/outlets or
so. *If* order matters to you (it may not always do) you can still use
the subpatch approach with dummy inlet~/outlet~ objects. 

And don't forget the other application of s~/r~ where you actually
*want* to have a delay of one block: feedback algorithms.

For s~/r~ may be not so useful as for delays and
tabsend~/tabreceive~,though. In my upcoming paper for the LAC2010 in
Utrecht, I present a way to do "control-rate" computations with signal
objects as an optimization technique. For example you can calculate the
"flatness" of a table by dividing the arithmetic and the geometric mean
of the table calculating everything in the signal domain.  There you
have three operations: two means and one division. You need to make sure
that you do both means before the division. The means are sent to a
table, and to make sure, they are written before the division I use
order forcing with subpatches.

> Is there some other way of "sorting" them??

Not that I know of.

> > It's the
> > same for messages, that's why I always keep telling newbies to
> > use more
> > [trigger] objects.
> 
> No it's not the same. 

I was comparing sorting DSP execution via subpatches/connections
to sorting messages via the [trigger] object. These are very similar
(well, not the same, but they are the equivalents.) I didn't mean to
compare s/r with s~/r~ here, which, as you correctly described, are
different. But that's because message handling and signal handling are
very different: signals are "always on" and execute parallel inside of a
block and are executed in reverse connection order ("top" objects are
executed first which is some kind of "depth-last") while messages are
scheduled on demand, one-by-one and depth-first.

But if you need to sort, use connections with signals and trigger with
messages. *When* you need to sort depends on what you want to do.

Ciao
-- 
Frank