|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.
|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
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.
On Sat, Apr 17, 2010 at 04:50:02PM +0200, Matteo Sisti Sette wrote:
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)
No, not always. Attached are two versions of your patch that have zero delay over three s~/r~.
*-sorted.pd uses explicit sorting, *-moved.pd exploits the current implementation of sorting, Pd does. Don't edit and save the second one, it may "break" again.
Ciao
Frank
On Sat, Apr 17, 2010 at 04:12:51PM +0200, Matteo Sisti Sette wrote:
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.
In Pd it's always (a) because patch cords define the execution order for signals. There's no ambiguity, but you cannot do loops this way ("DSP loop detected").
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???
Not always, but always when you do a loop. When you don't do a loop, you can order them so they have zero latency using patchcords/subpatches.
So my question is which of these is true: A) there is always a one-block latency between a s~ and a corresponding r~
No.
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.
Yes, there can be a latency, but you can make sure there is none by sorting manually using subpatches/patchcords, or you can make sure Pd introduces latency by doing a DSP loop. If you try both at the same time, you get an error message - the famous "DSP loop detected".
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.
I'm not sure I understand this sentence, but if you don't have loops, you can avoid latency between s~/r~, yes, by sorting.
Does anybody know the answer?
http://crca.ucsd.edu/~msp/techniques/latest/book-html/node120.html and following.
Ciao
Frank
Guys,
and how about PD-anywhere? How ZenGarden is influenced by? Isn't them so similar?
Thanks.
2010/4/18 Frank Barknecht fbar@footils.org
On Sat, Apr 17, 2010 at 04:12:51PM +0200, Matteo Sisti Sette wrote:
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.
In Pd it's always (a) because patch cords define the execution order for signals. There's no ambiguity, but you cannot do loops this way ("DSP loop detected").
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???
Not always, but always when you do a loop. When you don't do a loop, you can order them so they have zero latency using patchcords/subpatches.
So my question is which of these is true: A) there is always a one-block latency between a s~ and a corresponding
r~
No.
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.
Yes, there can be a latency, but you can make sure there is none by sorting manually using subpatches/patchcords, or you can make sure Pd introduces latency by doing a DSP loop. If you try both at the same time, you get an error message - the famous "DSP loop detected".
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.
I'm not sure I understand this sentence, but if you don't have loops, you can avoid latency between s~/r~, yes, by sorting.
Does anybody know the answer?
http://crca.ucsd.edu/~msp/techniques/latest/book-html/node120.htmlhttp://crca.ucsd.edu/%7Emsp/techniques/latest/book-html/node120.htmland following.
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2010-04-19 18:56, Vilson Vieira wrote:
Guys,
and how about PD-anywhere? How ZenGarden is influenced by? Isn't them so similar?
no, the only similarity between the 2 is, that both run on computers (you could say "smallish computers", but compared to computers some years ago, there is not so much difference in size between a sharp zaurus, an eee pc and a an I Phone.
Pd-anywhere is a Pd-port to arm-architectures (fixed point maths), whereas the I Phone has an FPU built in. so the original version of RjDj (aka Pd-on-I-Phone) only needed slight modifications, in order to interface with the OS. Pd-A had to do more modding, as it had to re-implement a lot of ugens, to fixed-pointify them. ZenGarden is a new implementation of the "Pd language" (which is a bit hard to do, as the language is nowhere defined)
all this is only guess work, as i am not part of these projects.
fgmasdr IOhannes
-
Frank Barknecht -
IOhannes m zmoelnig -
Matteo Sisti Sette -
Tim Blechmann -
Vilson Vieira