[PD] audio send recieve feedback quirk

Kyle Klipowicz kyleklip at gmail.com
Fri Feb 9 21:47:37 CET 2007


This is a great explanation! It makes total sense now.

~Kyle

On 2/9/07, Frank Barknecht <fbar at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>


-- 

http://theradioproject.com
http://perhapsidid.blogspot.com

(((())))(()()((((((((()())))()(((((((())()()())())))
(())))))(()))))))))))))(((((((((((()()))))))))((())))
))(((((((((((())))())))))))))))))))__________
_____())))))(((((((((((((()))))))))))_______
((((((())))))))))))((((((((000)))oOOOOOO




More information about the Pd-list mailing list