[PD] audio send recieve feedback quirk

[Frank Barknecht]

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__