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

[Matteo Sisti Sette]

Frank Barknecht escribió:

> 
> Attached is a very stupid example, which should show what I mean: Here
> various abstractions are layed out in a way, that they execute in order.
> Only one connection is used for order forcing, but still many s~/r~ are
> active, all properly ordered. 

Oh, I see, thank you.
At least that reduces the number of necessary wires to one, but I'm not 
sure that is viable in "real life". I'll try to think of some example.
You still have to enclose receives within a subpatch, and if you need to 
  connect it to the "outside" of the main patch, you are again facing 
the same original problem.... i think.

I will think of some simple-but-near-to-real-life example and post it.

In any case, at the very least, if order matters and you're building 
some complex patch, I think it soon becomes quite awkward and unmantainable.

I think it would be a great improvement to be able to impose (when one 
needs it) some precedence restrictions, i.e. dsp dependencies, between 
non-wired objects. For example, having a second optional creation 
argument in send~ and receive~ indicating a priority - or something. Pd 
would simply have to treat them the same way it treats dependencies 
forced by wire connections - and in case a loop is detected it would 
give the "loop detected" error (or a warning and ignore the restriction).

Without that, if I think of some of the complex architectures I built, 
if I had to modify them so as to guarantee sample accuracy, I'm afraid i 
would just have to port everything to something other than Pd....

By the way a similar improvement in the message domain would be the 
possibility to force an order among [r]s of a given [s]. In this case 
the interface would be simpler: just a numeric argument for the [r], for 
example: [s xxx], [r xxx 0], [r xxx 1], etc. where receives with the 
same number would be executed in unpredictable order.

-- 
Matteo Sisti Sette
matteosistisette at gmail.com
http://www.matteosistisette.com