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.
--
Matteo Sisti Sette
[email protected]
http://www.matteosistisette.com
#N canvas 713 213 844 359 12;
#X obj 111 199 vline~;
#X msg 112 160 1 \, 0 0 1;
#X obj 118 29 bang~;
#X obj 119 71 spigot;
#X obj 180 30 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X obj 118 101 t b b;
#X msg 196 74 0;
#X obj 113 132 t b b;
#X obj 247 207 tabwrite~ xxx;
#X obj 354 40 table xxx 256;
#X obj 111 226 s~ a;
#X obj 105 264 r~ a;
#X obj 106 292 s~ b;
#X obj 251 83 r~ b;
#X obj 252 110 s~ c;
#X obj 237 157 r~ c;
#X connect 0 0 10 0;
#X connect 1 0 0 0;
#X connect 2 0 3 0;
#X connect 3 0 5 0;
#X connect 4 0 3 1;
#X connect 5 0 7 0;
#X connect 5 1 6 0;
#X connect 6 0 4 0;
#X connect 7 0 1 0;
#X connect 7 1 8 0;
#X connect 11 0 12 0;
#X connect 13 0 14 0;
#X connect 15 0 8 0;
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
