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, [...]
Well, it does for direct wired connections obviously. So my error was to think that a [send~]-[receive~] pair was the same as an invisible wire.
Now the subpatch trick (btw thank you for pointing me to the documentation resources about it) doesn't help at all for [send~] and [receive~] does it? I mean it's applicable but if you can arrange the send and receive into subpatches that you have to connect physically, then you don't need the s~ and r~ in the first place...
So when you use send~s and receive~s, basically there's no way of enforcing a correct execution order?!?
On Sat, Apr 17, 2010 at 08:53:12PM +0200, Matteo Sisti Sette wrote:
Now the subpatch trick (btw thank you for pointing me to the documentation resources about it) doesn't help at all for [send~] and [receive~] does it? I mean it's applicable but if you can arrange the send and receive into subpatches that you have to connect physically, then you don't need the s~ and r~ in the first place...
If you only have a s~/r~ in your subpatch, then indeed you should probably not use them anyway. But very often you have more stuff happening, so you can sort larger parts of your alorithm.
As Tim wrote, the problem comes from Pd being a Max-like, two-dimensional programming language, where order can be ambigous, unless you employ one of the sorting mechanisms built into Pd. It's the same for messages, that's why I always keep telling newbies to use more [trigger] objects. It may come as a surprise that it also affects signals, but it's a closely related issue. Think of the patchcord as Pd's DSP way to say [t b a].
Ciao
Frank
-
Frank Barknecht -
Matteo Sisti Sette