|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!!!
now consider a case, when receive~ can changes its bus ...
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??
no. if you want to ensure the order of execution, to be (a), you have to put each part in subpatch, and connect them with a signal connection. there is a help patch about this, G05.execution.order.pd
A) there is always a one-block latency between a s~ and a corresponding r~
false
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.
true, but check the help patch
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.
false