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

@DesignDefault Welcome to the Forum...!

Sorry, this will be a lot for a newbie.

You will see in the video @ricky has linked to that the [phasor~] object controls the speed at which the array is being read.
So you will need to increase the number that it receives at its left inlet in order to increase the speed.
It is an audio rate inlet, so you will need [sig~] to convert a control rate 1 to a signal rate 1.
1 will play at normal speed, 2 at double that speed etc.

Unfortunately you will need to "catch" a moment in the [phasor~] loop using [edge~] and then increment that value to [sig~] by whatever increase you want each time that [edge~] outputs a bang.
Catching the exact moment that it loops can be awkward and you might well need to add or subtract a value from the output of [phasor~] before sending it into [edge~]

A more reliable method would be to use a [metro] to increase the [sig~] with the metro rate set by the value from [timer].

Also, before playback (it only needs to be done once for the array after it has been filled) extra data points should be added.
That will stop clicks as [phasor~] wraps back to the beginning of the array.
https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-of-an-array-for-4-point-interpolation-of-tabread4-ect
That will add 3 data points to the array, allowing [tabread4~] to correctly interpolate the samples at wrap around.
For that to work properly you should then add 3.... [+ 3] to the total number of samples after the [* 44.1]

Also, if you are running Pd at 48000Hz the [* 44.1] should be changed to [* 48] for the initial playback speed to be correct.
David.

@Pepe_mv98 Does your device now appear in the Pd top menu...... "Media", "Midi Settings..." ?
David.

@oid I had a similar opinion and similar worries.
Bluetooth pairing with a pairing password in Android sometimes ties the device to a single app, the data stream..... and even the connection state.... then not being available to any other.
No idea how that is dealt with in Linux..... so no comment except that the information will have to be found in Linux forums I think.
David.