> > |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 -- [email protected] http://tim.klingt.org The most wonderful opportunity which life offers is to be human. Henry Miller _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
