[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