I was hoping to use [bang~] to tell me when a 1024 sample FFT was finished so I could process the results ASAP, but it often bangs after only 64 samples when DSP is first turned on. Here's my test patch after one such run:
And here's what's inside the reblocked subpatch:
bang~runsAtTheEndOfEachDSPblock2.pd
After the first run it consistently reports 1024 as expected, but that first run usually shows 64, and only occasionally 1024. I saw 128 once, but haven't been able to reproduce it. I tried connecting the signal inlets and outlets in various ways but it didn't seem to matter. Am I overlooking something?

Update: I get similar results using [switch~]:
And the switched subpatch:
switch~ vs bang~.pd

Update #2: I added another test to the switch test and it contradicts the other two tests When viewed from inside [pd switchedSubPatch2], [bang~] happens at the right time, But if I run the original test immediately afterward, it still shows 64. There must be something about reblocking I don't understand.
switchedSubPatch2:
switch~ vs bang~.pd

IIRC at start the FIRST 64 samples are pushed at last into the buffer.

[---------------X]

Your FFT is computed right after (mostly with zeros) (thus bang~ triggers only 64 samples later).

@jameslo sorry for the bullshit i replied at first (deleted since)!

@Nicolas-Danet He he, no need to apologize, I'm grateful to get anything, BS or otherwise, in response to my own BS

Your explanation is consistent with the 64 sample result seen from the outside, but the phasor~ counter on the inside clearly runs 1024 samples before the [bang~] takes a snapshot and stops the subpatch. I'm not sure how to connect those two observations.

Here is yet another test, one that combines the two from the last test, but also tries to determine when samples start coming into the subpatch.
switch~ vs bang~2.pd
I got this result by starting dsp after clicking on the bang button and checking both toggles. The array1 inside the subpatch clearly shows only the last 64 samples populated by the [tabsend~], yet the outlet still passes 1023, meaning the phasor~ did count 1024 samples from 0. If I start dsp before clicking/checking, then array1 is completely filled but always has a discontinuity at some 64 sample boundary. For an FFT, there wouldn't be a discontinuity as long as I was inputting a static periodic signal of some harmonic frequency.

That other test on the right shows that there is a 960 sample latency through a 1024-blocked subpatch. That 64 sample difference has got to be related, but I can't understand how.

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.

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

@jameslo @Nicolas-Danet has visited this before and posted some insights during his research...... https://forum.pdpatchrepo.info/topic/12390/pd-s-scheduler-timing-control-rate-audio-rate-block-size-sub-sample-accuracy
A probably (but not necessarily) wrong thought.....
...... maybe until dsp is first turned on scheduling is not tied to audio ticks even though there are audio objects in the patch.
Pd being deterministic the events already scheduled (time stamped) before audio is turned on cannot be re-ordered. So the timing of control rate messages relative to the 64 sample window are unpredictable at the moment Pd first syncs audio ticks with the os?
Probably wrong as your patch is idle at load..... unless [bang~] is guesstimate scheduled without sync to the samplerate as dsp is off.
But I see Nicolas has it properly documented above.
David.

[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

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

After a day and a half of thinking about these answers, I think I understand the latency and the bang~ after only 64 samples at startup, but I can't explain the phasor~ counter. And while I have a tentative theory why array1 has discontinuities at random 64 sample boundaries, I can't figure out how to test the theory. But overall, that's progress, thanks! So let me pivot and ask the underlying practical question: 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?
switched1024FFT:

Edit: Hmm, I wonder if I specified 16X overlap I would get results closer to what I'm expecting (maybe naively?) from my earlier tests? I'd probably have to run the subpatch for 1024/44100 seconds to prime the reblocking pipeline....

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...

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

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.

@Nicolas-Danet OK, I think I get it. 1024 samples have "passed" (according to the phasor~ counter) inside the reblocked subpatch because sample processing lurches forward 1024 samples once every 16 64 sample blocks processed by the enclosing patch. My error is in thinking that sample counters should all progress at the same rate, like two different wall clocks would. When dsp processing starts, PD arranges all subpatches regardless of blocking to immediately start generating audio if necessary, so in the case of a 1024 sample reblocking, it just fills the first 960 samples with 0's so it can start outputting them. But it has to wait for the first 64 real samples before it has a complete 1024 vector to process.

RE the array, you can force the drawing by either clicking on it somewhere (and ignoring the point you just created), or by just leaving the subpatch closed and opening it when you want to take a look. There is also list view, which is the only way I knew that the discontinuities were on 64 sample boundaries. So it's less the array GUI element that I'm concerned with, and more the behavior of [tabsend~]. [tabreceive~] is used to implement things like Hann windows, so it has to enforce a 1-1 ordered correspondence between the source table and the current vector. I assume that [tabsend~] makes similar guarantees, but I was wondering if the switch~ was messing things up. 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? When dsp is off, does PD stop accumulating the 1024 block for the subpatch? The discontinuity goes away when I declare [switch~ 1024 16 1], and it also causes the phasor~ counter to report approx 64 (because phasor~ is configured in cycles per second and so has to adjust to the current blocking, overlap, and oversampling). <BS in last sentence corrected/>

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!

@Nicolas-Danet You've already helped me plenty, thank you.

I made one more test and I'm convinced that without overlap, you can't use switch~ to process one 1024 block unless that discontinuity doesn't matter to you:
switched1024subPatch:
switch~ with reblocked vector.pd
If you change to [switch~ 1024 16], you stop seeing discontinuities. So that discontinuity in the [tabsend~]/array1 test result was real!

Should I edit the title of this topic to more accurately describe what's in it?

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.