Matteo Sisti Sette escribió:
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.
Ok I did some tests and it seems the answer is (A)
With this:
[s~ a] [r~ a] | [s~ b] [r~ b] | [s~ c] [r~ c]
you get a 3-block delay.
It is quite a shock for me to find out this (though it is much better than B anyway). I always thought that send/receive~ pairs were exactly equivalent to invisible wires! (and never tried doing loops just as I avoid them when connecting wires)
I often need to use sends and receives just "for programming reasons", that is creating complex structures by encapsulating, creating abstractions, etc, and so obtaining almost-scalable structures, where you can increase the "number of things" by just copy-pasting a number of instances of some abstraction but without copying the wiring.
That is, creating loop-free graphs that could be expressed with visible wires but are more elegantly and scalably written with sends and receives. Fortunately I never did block-accuracy-demanding applications up to now (that's why i didn't notice the problem), however it is a pity that an unnecessary one-block delay is added on every single send-receive pair.
That means that if you need sample-accuracy (to the extent that it is possible) you simply cannot apply some basic design techniques that are in my opinion the only way to achieve complexity...
So I think an invisible-wire-like version of send/receive~ would be needed.....
Attached patch shows the three-block delay with the send-receive chain.