[PD] understanding block latency

[Alexandre Torres Porres]

Hmmm... It seems that occasionally, the bang into the subpatch doesn't get
there in the actual start of the block, but in the middle of it. Hence it
gives us the illusion of being synced up with the parent. But it's not,
it's just that the printed output is in fact delayed already. But that
doesn't mean the actual block is delayed, of course.

Now I made sense of it, right? :)

thanks!

Em sex, 11 de jan de 2019 às 18:57, Alexandre Torres Porres <
porres at gmail.com> escreveu:

> Em sex, 11 de jan de 2019 às 18:23, Christof Ressi <christof.ressi at gmx.at>
> escreveu:
>
>>
>> the reason is that a reblocked subpatch has to wait for (subpatch
>> blocksize - parent blocksize) samples until it has enough samples to
>> process its first block. before that it will output zeroes.
>
>
> Ok, my intuition was telling me that it needs to wait for "subpatch's
> blocksize" samples until it has enough samples to process its first block.
> But trying to make sense, it seems that for the first processing round it
> waits and fills with zeros until it can receive the block of 64 samples
> from the parent so it completes its block size, so we actually have the
> first bigger block of samples containing the 64 sample block from the
> parent! If you measure the difference, the latency is actually a bit
> shorter. Yeah, that makes sense in the end, phew...
>
> The confusion comes from expecting that the larger reblocked subpatch
> needed to start and get its first samples from the incoming signal sent by
> the parent. Then you'd have to wait until a whole block is filled until it
> gets output next. Then the delay would be the block size, right?
>
> Now onto the other part, which I can't figure out yet. Cause in my
> attached example, what I just mentioned in the last paragraph actually
> happens. You can have the blocks synced up and you can see in the output of
> print~ that the incoming block from the parent counts from 1 to 64, here's
> the console print.
>
>
> *input:*
> 1  2  3  4  5  6  7  8
> 9  10  11  12  13  14  15  16
> 17  18  19  20  21  22  23  24
> 25  26  27  28  29  30  31  32
> 33  34  35  36  37  38  39  40
> 41  42  43  44  45  46  47  48
> 49  50  51  52  53  54  55  56
> 57  58  59  60  61  62  63  64
>
> The reblocked subpatch then counts from 1 to 128!
>
> *subpatch:*
> 1  2  3  4  5  6  7  8
> 9  10  11  12  13  14  15  16
> 17  18  19  20  21  22  23  24
> 25  26  27  28  29  30  31  32
> 33  34  35  36  37  38  39  40
> 41  42  43  44  45  46  47  48
> 49  50  51  52  53  54  55  56
> 57  58  59  60  61  62  63  64
> 65  66  67  68  69  70  71  72
> 73  74  75  76  77  78  79  80
> 81  82  83  84  85  86  87  88
> 89  90  91  92  93  94  95  96
> 97  98  99  100  101  102  103  104
> 105  106  107  108  109  110  111  112
> 113  114  115  116  117  118  119  120
> 121  122  123  124  125  126  127  128
>
> But the output is actually still delayed by (blocksize - 64). In the
> output I need a [delay 1 64 samp] object to get the same incoming block.
>
> And I can't actually get my head around that, just seems weird and I can't
> make sense.
>
> Cheers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20190111/db1b80ec/attachment.html>