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