Following a previous discussion < https://forum.pdpatchrepo.info/topic/12905/bang-bangs-before-the-end-of-a-dsp-block-at-startup > i'll post there a series of examples to explain what's going on under the hood with reblocked subpatches. It is based on experiments i done with my fork, but AFAIK it is exactly the same in Pure Data (there are minor differences but IIRC it doesn't change global behaviour). Please correct me if you thing something is wrong in order to avoid to make things more impenetrable in the future that it is already now.

• Up: [block~256]
• Down: [block~ 32]
• Downsample: [block~ 32 1 0.5]
• Upsample: [block~ 128 1 2]
• Overlap: [block~ 128 2]
• Overlap: [block~ 512 4]

I do that because i always forget how it is done, and must bang my head again and again.

Thus: first reblocking up (i.e. [block~ 256])!

[---a]  !  [---A] #0
    ^       ^
[b---]     [---A] #1
 ^           ^
[bc-a]     [---A] #2
  ^           ^
[bcda]     [---A] #3
   ^           ^
[bcde]  !  [BCDE] #4
    ^       ^
[fcde]     [-CDE]
 ^           ^
[fgde]     [--DE]
  ^           ^
[fghe]     [---E]
   ^           ^
[fghi]  !  [FGHI]
    ^       ^

a b c d e f g h i / - - - A B C D E F

// [block~ 256]

BLOCK FREQUENCY+1
BLOCK PERIOD+4
INLET SIZE+256
INLET WRITE+192
INLET HOP+256
OUTLET SIZE+256
OUTLET HOP+256

#+0#        // First tick.

P+192/+64   // Prologue: write 64 samples at 192 of the buffer in.

R+0/+256    // Read 256 samples from the buffer in to be processed.
W+0/+256    // Write the result in the buffer out.

E+0/+64     // Epilogue: read 64 samples at start from the buffer out.

#+1#

P+0/+64     // Prologue: write 64 samples at start of the buffer in.
E+64/+64    // Epilogue: read 64 samples at 64 from the buffer out.

#+2#

P+64/+64
E+128/+64

#+3#

P+128/+64
E+192/+64

#+4#

P+192/+64

R+0/+256
W+0/+256

E+0/+64

#+5#

...

@Nicolas-Danet This is amazing, thanks. Would you mind adding more detail explaining your notation? For instance, in:
what do the up arrows, grey numbers on the right, and exclamation point represent? I think I know but I'd rather have you confirm it.

What does this mean?

Also, can you explain what each of the declarations mean (assuming they're declarations)?

1. The arrows point to the place where the signal is put (during the prologue) into the subpatch buffer in, and from where the signal is pulled out (during the epilogue) from the subpatch buffer out. Note that each letter represents 64 samples (oops, i should have said this first).

2. The #numbers refer to those in the log file (i.e. starting with "BLOCK FREQUENCY") for each example.
   It is the DSP tick tag (e.g. "#+0#").

3. The exclamation marks when the DSP is triggered (computed) in the subpatch.

4. On the left "a b c d e f g h i" is the signal in, whereas on the right "- - - A B C D E F"" is the signal out. That means that for the first 64 samples labeled "a" you get 64 samples of "-" (zeros). Then for "b" you have zeros again, for "c" also. For the fourth vector "d" you obtain "A" (that is the computed signal of "a").

5. BLOCK FREQUENCY ... OUTLET HOP
   Those are messages logged in my fork when the DSP graph is builded. It helps me to understand what's going on.
   < https://github.com/Spaghettis/Spaghettis/blob/054786098f340d8683efd9b5b5f2c1df4c8f1f56/src/dsp/graph/d_block.c#L85 >
   Roughly:
   BLOCK FREQUENCY is the number of times the child ticks for each DSP tick in parent.
   BLOCK PERIOD at contrary is the number of times the parent ticks for one tick in child.
   INLET SIZE is the size of the buffer in.
   INLET WRITE is the position to write into the buffer at start.
   INLET HOP ... is the hop.
   OUTLET SIZE is the size of the buffer out.
   OUTLET HOP ... is the hop too!

@Nicolas-Danet So why isn't BLOCK FREQUENCY 0.25 in the reblocking up example?

Those values have no mathematic meaning. They correspond to C code variables. Thus the "f = 1 / T" is not true here. It is just integers that are used to manage the gears between the parent and the child. Don't try to interpret them whitout looking into the sources at the same time. Notice that in that case, one of both (period or frequency) must be always equal to 1 as it is checked here: < https://github.com/Spaghettis/Spaghettis/blob/054786098f340d8683efd9b5b5f2c1df4c8f1f56/src/dsp/graph/d_block.c#L72 >. The machinery in my fork is very closed to the Pure Data's one. The only difference is that in Spaghettis the DSP can not be stopped at the middle of the block quantum (i.e. it will wait the end of the blocksize stride to be switched off).

Today [block~ 512 4] (i.e. 4 overlaps).

block.512.4.pd

I let you decipher the reports. You should be able if you understand the previous examples.
Notice that the shift here is done onto 6 blocks (384 samples).
Thus [1 2 3 4 5 6 7 8] becomes [3 4 5 6 7 8 7 8].
Here for convenience i don't make the difference between concecutive computations onto the same signal. I mean when it is (4A) it is in fact (A+A'+A''+A''') if i had kept notation in previous [block~ 128 2] example.

[- - - - - - - a]  !  [-  -  -  -  -  -  -  A ]     #0
               ^       ^
[- - - - - a b a]     [-  -  -  -  -  -  -  A ]     #1
             ^            ^
[- - - - - a b c]  !  [B  C  -  -  -  -  -  2A]     #2
               ^             ^
[- - - a b c d c]     [B  C  -  -  -  -  -  2A]     #3
             ^                  ^
[- - - a b c d e]  !  [2B 2C D  E  -  -  -  3A]     #4
               ^                   ^
[- a b c d e f e]     [2B 2C D  E  -  -  -  3A]     #5
             ^                        ^
[- a b c d e f g]  !  [3B 3C 2D 2E F  G  -  4A]     #6
               ^                         ^
[b c d e f g h g]     [3B 3C 2D 2E F  G  -  4A]     #7
             ^                              ^
[b c d e f g h i]  !  [4B 4C 3D 3E 2F 2G H  I ]     #8
               ^       ^
[d e f g h i j i]     [-  4C 3D 3E 2F 2G H  I ]     #9
             ^            ^
[d e f g h i j k]  !  [J  K  4D 4E 3F 3G 2H 2I]     #10
               ^             ^
[f g h i j k l k]     [J  K  -  4E 3F 3G 2H 2I]     #11
             ^                  ^
[f g h i j k l m]  !  [2J 2K L  M  4F 4G 3H 3I]     #12
               ^                   ^
[h i j k l m n m]     [2J 2K L  M  -  4G 3H 3I]     #13
             ^                        ^
[h i j k l m n o]  !  [3J 3K 2L 2M N  O  4H 4I]     #14
               ^                         ^
[j k l m n o p o]     [3J 3K 2L 2M N  O  -  4I]     #15
             ^                              ^
[j k l m n o p q]  !  [4J 4K 3L 3M 2N 2O P  Q ]     #16
               ^       ^
[l m n o p q r q]     [-  4K 3L 3M 2N 2O P  Q ]     #17
             ^            ^
[l m n o p q r s]  !  [R  S  4L 4M 3N 3O 2P 2Q]     #18
               ^             ^

a / [- - - - - - - a]
c / [- - - - - a b c]
e / [- - - a b c d e]
g / [- a b c d e f g]
i / [b c d e f g h i]
k / [d e f g h i j k]
m / [f g h i j k l m]
o / [h i j k l m n o]
q / [j k l m n o p q]
s / [l m n o p q r s]

a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  p  q  r  s 
-  -  -  -  -  -  -  4A 4B 4C 4D 4E 4F 4G 4H 4I 4J 4K 4L

// [block~ 512 4]

BLOCK FREQUENCY+1
BLOCK PERIOD+2
INLET SIZE+512
INLET WRITE+448
INLET HOP+128
OUTLET SIZE+512
OUTLET HOP+128

#+0#

P+448/+64

R+0/+512
W+0/+512

E+0/+64

#+1#

SHIFT+128/+384      // Shift last 384 samples (6 * 64) at start.
P+384/+64

E+64/+64

#+2#

P+448/+64

R+0/+512
W+128/+512

E+128/+64

#+3#

SHIFT+128/+384
P+384/+64

E+192/+64

#+4#

P+448/+64

R+0/+512
W+256/+512

E+256/+64

#+5#

SHIFT+128/+384
P+384/+64

E+320/+64

#+6#

P+448/+64

R+0/+512
W+384/+512

E+384/+64

#+7#

SHIFT+128/+384
P+384/+64

E+448/+64

#+8#

P+448/+64

R+0/+512
W+0/+512

E+0/+64

#+9#

SHIFT+128/+384
P+384/+64

E+64/+64

#+10#

P+448/+64

R+0/+512
W+128/+512

E+128/+64

#+11#

SHIFT+128/+384
P+384/+64

E+192/+64

#+12#

P+448/+64

R+0/+512
W+256/+512

E+256/+64

#+13#

SHIFT+128/+384
P+384/+64

E+320/+64

#+14#

P+448/+64

R+0/+512
W+384/+512

E+384/+64

#+15#

SHIFT+128/+384
P+384/+64

E+448/+64

#+16#

P+448/+64

R+0/+512
W+0/+512

E+0/+64

#+17#

SHIFT+128/+384
P+384/+64

E+64/+64

#+18#

P+448/+64

R+0/+512
W+128/+512

E+128/+64

#+19#

SHIFT+128/+384
P+384/+64

E+192/+64

#+20#

P+448/+64

R+0/+512
W+256/+512

E+256/+64

#+21#

SHIFT+128/+384
P+384/+64

E+320/+64

#+22#

...

A degenerate case that has probably no utility but that i post for fun.

The [block~ 32 2] (reblocked down overlapped twice)???

block.32.2.pd

Notice that here the letters represents 16 samples (64/4). And since it is always complete at each tick just one of them is required. The result is strange. Each DSP vector is sliced in four pieces, and combined. Is it normal. I don't know? But it can be awesome! For what?

TBH I did that kind of thing only to be sure that i didn't make an error while refactoring Pure Data.

[a b c d]  !  [A B - -]
              [- C D -]
              [- - A B]
              [D - - C]

-->       [A+D B+C A+D B+C]

// [block~ 32 2]

BLOCK FREQUENCY+4
BLOCK PERIOD+1
INLET SIZE+64
INLET WRITE+64
INLET HOP+64
OUTLET SIZE+64
OUTLET HOP+16

#+0#

P+0/+64

R+0/+32
W+0/+32
R+32/+32
W+16/+32
R+0/+32
W+32/+32
R+32/+32
W+48/+32

E+0/+64

#+1#

...

@Nicolas-Danet Hey Nicolas, your description of [block~ 128 2] doesn't match my understanding (maybe because I misunderstood your description ). Look at this test:
overlap blocks 128 2.pd
On the input side we are in agreement, it's a sliding window. On the output side, my understanding is that the sliding windows are just summed at a 64 sample offsets. This is hard to describe in words, so I aligned the tables in the subpatch to suggest how they are summed. As far as I know, there is no vector reversal. What do you think?

Edit: Oh wait, our outputs are the same at the 64 block level (A+A' B+B' C+C'....) so I'm probably reading-comprehension challenged, but I still wonder why you describe it in terms of vector reversal. The vector is definitely not reversed at the sample level.

@Nicolas-Danet RE [block~ 32 2], in my testing I've found that overlapped windowing is broken WRT Hann windowing (used in FFT) if you don't choose a block size that is >= the overlap factor * the oversampling factor * 64, so my concern is that you've just documented (and copied into Spaghettis) some undocumented/unspecified Pd behavior. Maybe there are some other applications of overlap that depend on this behavior, but I'm not aware of any. In the following example, you can verify that the output of [pd 4xoverlapBlockSubpatch] is messed up in a unique way for each subpatch block size less than 256 = 4 * 1 * 64. It doesn't matter what the enclosing patch's block size is. All the other subpatch block sizes >= 256 work and produce the same output. I've only tested 4 as the overlap factor because that's the only one I know how to use with Fourier resynthesis.
overlap blocks3.pd<= ignore poor choice of patch name

@jameslo: Sorry if my notation is ambiguous. It doesn't refer at all to vector reversal. I used A+A' just to emphasize the fact that it is the sum of the signal "a" processed one time (to get "A") plus the same signal "a" processed another time (to get "A'"). It could be A0+A1 or anything else (better). Note that it is simply 2*A in my (your) examples (but it could be not the case).

reading-comprehension challenged

It is. Just after one week working on other things, i already forgotten all that stuff!

PS: I never use [bang~] in my tests since it almost never does what you want to do in those contexts and because i removed it in Spaghettis!

PS2: These examples have been done to understand exactly what is happening under the hood without any care to what overlapping/reblocking is used for (and surely that [block~ 32 2] is weird and useless).