[PD] PD] Zen Garden re-implementing the wheel in C++?
fbar at footils.org
Sun Apr 18 10:29:16 CEST 2010
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:
> 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
> 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~
> 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?
More information about the Pd-list