Thanks, it makes me want to read the Katjaas's blog!

But... what's in it?

After a quick look in the code it seems that switch by-passes all the synchronisation mechanism that glue the perform rate inside with buffering from outside < https://github.com/pure-data/pure-data/blob/d5766fd0600a5444a7e26754bed4f175d96ac568/src/d_ugen.c#L266 >. It could be the origin of discontinuities when it is put ON/OFF/ON. That's pure speculation that would requires more investigations.

When dsp is off, does PD stop accumulating the 1024 block for the subpatch?

I suppose, but i'm not sure.

The message to turn on dsp can come between any 64 sample block, could that be related to the timing of the discontinuity I'm seeing?

I guess that the switch can be trigger anywhere (modulo 64) in the middle of 1024 accumulation.

At that point i can not help you more. I"m not able to tell you exactly what's going on for such tricky scenario in Pure Data. I already get monthes of headaches to understand it once < https://forum.pdpatchrepo.info/topic/11738/spaghettis-yet-another-fork-of-pure-data/7 >. I don't want to do it again.

Try the pd-list if you want a enlightened response!

1. To avoid proliferation of bullshits on the web, please correct me if you think that something is wrong.
2. Overlap is more complex, and TBH i don't remember the stuff.
3. For masochists < https://github.com/nicolasdanet/T/blob/master/tests/reblock/Z06.overlap.txt >.

but I can't explain the phasor~ counter.

Notice that in this example we don't have/use any signal in (neither out).
But it is best to illustrate a general case where it could be.

[---------------a]  !  [---------------A]    bang
                ^       ^

Last 64 vector is pushed in buffer in.
Perform method is done with a 1024 vector size.

• The [phasor~] object ramps from 0 to 1023.
• The [phasor~] signal is thus [0 1 2 3 ... 1021 1022 1023]
• The [snapshot~] object grabs the last sample in the signal in, that is 1023.
• The [bang~] object registers a zero delay clock.

First 64 vector is read from buffer out.
The [bang~] clock fires.
The [snapshot~] content is reported, that is 1023. Tada!

[bcdefghijklmnopq]  !  [BCDEFGHIJKLMNOPQ]    bang
                ^       ^

Same thing later and for ever!

momo.pd

And while I have a tentative theory why array1 has discontinuities at random 64 sample boundaries,

AFAIK the array's content is not redrawed each time it is filled. I had a quick look onto the code and it seems done once per second. Moreover as the DSP is quickly stopped, it might even not done at all. Thus it is a confusing approach in order to understand what's going on under the hood.

In the following patch, assuming DSP is on and I've discarded the first switch~ run, will [rfft~] transform one complete, chronologically ordered 1024 sample vector each time I click on the 1 message?

AFAIK, yes. The FFT of [---------------a] then the FFT of [bcdefghijklmnopq] and so on...

Concerning the difference of 960 ; if you observe the figure i posted above in the thread, you can see that when you put "q" for instance in the reblocked subpatch you get "B" from it. The [snapshot~] object report the last value of the vector. The "q" is the 17th letter of the (english) alphabet. Thus in your example the value is (17 * 64) = 1088. For "B" it is (2 * 64) = 128. The difference is (1088 - 128) = 960. And so on since you have always the same offset later.

Note that i used lower-case and upper-case to emphasize that the DSP vector has been transformed by operations in the subpatch (e.g. FFT). It is exactly the same thing if you just connect the [inlet~] to the [outlet~].

jojo.pd

[bang~] object is pretty simple. Each time a DSP tick is performed, it triggers a clock with zero delay. That means that as soon as a control block will be proceeded (interleaved in 64 samples DSP vectors) it bangs. With the patch below, i get 64 at first then 1024 after... as expected.

toto.pd

Understand reblocking is hard because a lots of objects (e.g. used to debug) doesn't work as expected in that case.

At left is what (signal in) is buffered in reblocked patch.
At right is what is read out (signal out) at each tick.
Exclamation marks when the reblocked subpatch DSP is performed.
There are 16 slots here since it is the result of 1024 / 64.

[---------------a]  !  [---------------A]    bang
                ^       ^
[b--------------a]     [---------------A]
 ^                       ^
[bc-------------a]     [---------------A]
  ^                       ^
[bcd------------a]     [---------------A]
   ^                       ^
[bcde-----------a]     [---------------A]
    ^                       ^
...

[bcdefghijklmno-a]     [---------------A]
              ^                       ^
[bcdefghijklmnopa]     [---------------A]
               ^                       ^
[bcdefghijklmnopq]  !  [BCDEFGHIJKLMNOPQ]    bang
                ^       ^
[rcdefghijklmnopq]     [-CDEFGHIJKLMNOPQ]
 ^                       ^
[rsdefghijklmnopq]     [--DEFGHIJKLMNOPQ]
  ^                       ^
[rstefghijklmnopq]     [---EFGHIJKLMNOPQ]
   ^                       ^
...

Note that the indexes to write/read in subpatch are properly saved later when DSP is turned off.

IIRC of course.