[PD] Invisible wires was Re: PD] Zen Garden re-implementing the wheel in C++?

[Matteo Sisti Sette]

Matteo Sisti Sette escribió:

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

Ok I did some tests and it seems the answer is (A)

With this:

[s~ a]
[r~ a]
  |
[s~ b]
[r~ b]
  |
[s~ c]
[r~ c]

you get a 3-block delay.

It is quite a shock for me to find out this (though it is much better 
than B anyway). I always thought that send/receive~ pairs were exactly 
equivalent to invisible wires! (and never tried doing loops just as I 
avoid them when connecting wires)

I often need to use sends and receives just "for programming reasons", 
that is creating complex structures by encapsulating, creating 
abstractions, etc, and so obtaining almost-scalable structures, where 
you can increase the "number of things" by just copy-pasting a number of 
instances of some abstraction but without copying the wiring.

That is, creating loop-free graphs that could be expressed with visible 
wires but are more elegantly and scalably written with sends and receives.
Fortunately I never did block-accuracy-demanding applications up to now 
(that's why i didn't notice the problem), however it is a pity that an 
unnecessary one-block delay is added on every single send-receive pair.

That means that if you need sample-accuracy (to the extent that it is 
possible) you simply cannot apply some basic design techniques that are 
in my opinion the only way to achieve complexity...

So I think an invisible-wire-like version of send/receive~ would be 
needed.....

Attached patch shows the three-block delay with the send-receive chain.

-- 
Matteo Sisti Sette
matteosistisette at gmail.com
http://www.matteosistisette.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: send-receive-delay.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100417/d50d75ec/attachment.txt>