|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.