[PD] PD] Zen Garden re-implementing the wheel in C++?

[Frank Barknecht]

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