[PD] PD] Zen Garden re-implementing the wheel in C++?

[Matteo Sisti Sette]

 > |adc~|
 > |
 > |send~ foo|
 >
 > |receive~ foo|
 > |
 > |dac~|
 >
 > it execution order is ambiguous.
 >
 > either (a) adc-send-receive-dac or
 > (b) receive-dac-adc-send.
 > the case (b) introduces one sample block of latency between
 > send and receive, (a) doesn't introduce any latency.

I don't think it is more ambiguous than the order of execution of this:

[adc~]
  |
[dac~]

Either (a) adc-dac or (b) dac-adc. Like in your example, the case (b) 
introduces one sample block of latency between adc and dac, the case (a) 
doesn't

...well, then the case (b) is the wrong one and the case (a) is the 
right one!!!

Please anybody correct me if I am wrong, but I think _unless there are 
loops in the graph_ there is _always_ an order that ensures no added 
latency, and finding out that order is all what dsp-graph computing is 
about!!! I always thought Pd would take care of that.... perhaps doesn't 
it??

However the problem does arise when there are loops.

Indeed loops by direct wiring are not allowed in Pd.
But to my surprise I find out that loops using send~ and receive~ are.
So does a send~-receive~ pair always implicitly have a one-block latency???

This is not only a problem of dynamically changing the dsp graph. Even 
if the graph is static, the ambiguity of not knowing whether there is or 
there isn't a one-block latency in a particular connection, or where 
exactly the necessarily-existing-one-block-latency is in a dsp loop, can 
be very relevant to the resulting signal.

So my question is which of these is true:
A) there is always a one-block latency between a s~ and a corresponding r~
B) there _can_ be a latency, depending on the execution order Pd choses, 
and you can't know whether there will or won't be.
C) there _can_ be a latency, but if there is no dsp loop on the graph, 
then you can be sure there won't be any avoidable latency due to 
execution order.


Does anybody know the answer?


thanks
m.

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