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

[Tim Blechmann]

>  > |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


-- 
tim at klingt.org
http://tim.klingt.org

The most wonderful opportunity which life offers is to be human.
  Henry Miller