@jameslo "Even if I run it via a delay with a fractional block time it's the same."

Yes, the same data...... but 1 block later........ vs.pd
In tabwrite~ vs print~ you banged [tabwrite~] also after the delay..... effectively delaying the data and the display.
If you start [tabwrite~] first then you see that the data is written in the next block.
And if you link the top bang to print~ you will see that it is different.
But anyway..... the data write has simply been delayed by one block.

So my premise that [tabread~] collects data from the previous block was wrong in a previous post... of course....!
Because Pd being deterministic stuff only happens after it has been asked for.
David.

@jameslo Busy elsewhere, but still thinking about this of course.

vline~blockquantiser...
Interesting that [print~] prints identical blocks for both bangs (actually not very interesting).
[tabwrite~] starts writing the array from the beginning of the previous block when it gets its bang from [del 1] at the end of that block (as I mentioned above) and then writes 192 points...... but the spigot then only lets through the next bang to [vline~] 64 samples later ... ([bang~] every block.... Godot).....
I.e the two [print~]'s are simply one block apart as displayed in the array.

But I admit to also having lost track of the actual problem.
Do you want to trigger [vline~] between blocks?
If so you should bang the message to [vline~] from [del 1] instead of your sub-patch inlet and then [vline~] will be scheduled to start within the block (at 1 millisecond in).
But if you wanted it to be triggered at the next boundary vline~blockquantiser does exactly that...!.
hmm.pd
David.

@jameslo Funny [list]...... my sort of post, more so as I get older and forgetful..
David.

@jameslo Pretty sure it is documented here...
Messages are received and run out during an audio block?...... but the resulting instructions are not passed to an object until the next boundary?..... at which time they will be scheduled to be acted upon within the next block if the object can do so?.
I admit in advance that I am not certain that is what is being declared below.

"2.5. scheduling
Pd uses 64-bit floating point numbers to represent time, providing sample accuracy and essentially never overflowing. Time appears to the user in milliseconds.
2.5.1. audio and messages
Audio and message processing are interleaved in Pd. Audio processing is scheduled every 64 samples at Pd's sample rate; at 44100 Hz. this gives a period of 1.45 milliseconds. You may turn DSP computation on and off by sending the "pd" object the messages "dsp 1" and "dsp 0."

In the intervals between, delays might time out or external conditions might arise (incoming MIDI, mouse clicks, or whatnot). These may cause a cascade of depth-first message passing; each such message cascade is completely run out before the next message or DSP tick is computed. Messages are never passed to objects during a DSP tick; the ticks are atomic and parameter changes sent to different objects in any given message cascade take effect simultaneously.

In the middle of a message cascade you may schedule another one at a delay of zero. This delayed cascade happens after the present cascade has finished, but at the same logical time".
http://puredata.info/docs/manuals/pd/x2.htm

And I also wonder whether we are actually able to graph the result properly.... maybe [print~] is the only way as it gets the data from the next block, whereas [tabread] gives data from the last block?
David.