This is a great explanation! It makes total sense now.
~Kyle
On 2/9/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
But it is true that creation order affects this? Can you explain how, since I could never quite get it worked out properly and it cost me many hours and maybe even a few gray hairs ;-)
It's similar to normal messages, just replace [trigger] with [pd x] if you want explicit ordering.
Whereas in the message world, unknown ordering of "fanned" connections is the problem, that is solved with [trigger ...], in the signal world, non-local connections like s~, throw~ or delwrite~ are possible culprits that may introduce block-sized delays.
The basic problem is, that not all dsp-objects are calulated at the same time. They are calculated in the same block of samples, but if you have two signal objects one has to be calculated before the other.
This ordering is easy if you have direct connections:
[noise~] | [lop~ 5] |
[noise~ 1] will be calculated first, then [lop~ 5] can filter the result as input.
Or as Miller puts it:
Although the tilde objects in a patch may have a complicated topology of audio connections, in reality Pd executes them all in a sequential order, one after the other, to compute each block of audio output. This linear order is guaranteed to be compatible with the audio interconnections, in the sense that no tilde object's computation is done until all its inputs, for that same block, have been computed.
http://crca.ucsd.edu/~msp/techniques/latest/book-html/node120.html
Now much like fanning message connections this ordering can become ambigous if non-local signal connections are involved:
[noise~] | [s~ X]
[r~ X] | [lop~ 5] |
Now just tell from looking, which signal-block of [noise~] the [lop~ 5] will filter: the current one or the previous one? You can't tell, just as you cannot tell the result of this addition by just looking:
[1( |
|
[+ ] | 1 or 2?The message solution is a trigger:
[1( | [t a a] | / [+ ] | 2
The signal solution are two sub-patches:
[pd noise] ==> [noise~] | | | [s~ X] [outlet~] <- dummy! | [pd lop_5] ==> [inlet~] <- dummy!
[r~ X] | [lop~ 5]Because there is a dummy-signal connection, now the ordering is well-defined again through the signal-connection: The upper subpatch will be calculated first, so the lop~ will filter the current block - often this would not matter, though.
But now this explicit ordering breaks horribly if you create a dsp-loop. That is, if you put a [r~ Y] in the upper and a [s~ Y] in the lower subpatch. Pd will warn you about this with its "DSP-loop detected" error message.
I hope this will make the issue a bit clearer, again I would recommend to study these two pages closely: http://crca.ucsd.edu/~msp/techniques/latest/book-html/node120.html http://crca.ucsd.edu/~msp/techniques/latest/book-html/node121.html
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list