In the following patch, when I [bng] manually, the vline~ and tabwrite~ start exactly at the same time, as desired, but when I turn on the [metro], the start of the vline~ is randomly delayed (by up to one block, I'm guessing).

What's going on?

Replacing the vline~ with line~ and the appropriate input messages eliminates the start time problem, although line~ appears to round the duration of its ramp down to the nearest block.

[bng] [tgl]
| |
| [metro 500]
| /
[t b b]
| |
| [0, 1 2(
| |
| [vline~]
| /
[tabwrite~ array]

if you put a [block~ 1], will it work?

Timing in Pd can be a big deal, and to understand it, you need to know how message-rate (or control-rate, as it's often called) and audio-rate objects deal with it. This isn't exclusive to Pd, btw. It's common among pretty much all music programming, and if you ever want to write LV2, VST, AU, etc., plugins, you'll need to know this stuff, too.

In Pd (as with most music programming languages), signals are passed from object to object in what are called "blocks" or "vectors" ("vector" is more common from a math standpoint, but in Pd world "block" is the term). Objects don't pass signals sample-by-sample, rather, they pass them in groups, or "blocks", of samples. By default, it is 64 samples. An object will take a set of 64 samples, process them, and then send a 64 sample output to the next object.

Messages, on the other hand, are not bound by this. They act immediately, and the timing in Pd for these objects is really good. [metro], for example, has been known to not only be sample accurate, but sub-sample accurate.

Now, for efficiency's sake, audio-rate objects will typically take message-rate input at block boundaries, meaning that when it receives a message, it waits until the previous block is done computing to take effect. That is what [line~] does. Every message you send to it only starts at the beginning of the next block of 64 samples. Obviously, this messes with the accuracy of message-rate objects, but in most cases it isn't a noticeable problem. [vline~], on the other hand, will act in the middle of a block. When it receives a messages, say, 21 samples in, it will start it's ramp 21 samples in the next block. I emphasized that to make it clear: once a block has started computing, it can't be interrupted; therefore, sample accuracy has to be delayed by one block. But, again, this doesn't matter, because everything that needs sample accuracy will be delayed by that one block, so they will all be in time with each other.

That is all just a long way of saying that [vline~] is sample accurate and [line~] isn't

I don't know why this is, but it seems that the GUI objects in Pd only send their messages at block boundaries. So that is why they line up with [bng] but not with [metro].

Maelstorm, many thanks for this detailed explanation.

I was under the mistaken belief that bangs and messages were only transmitted at block boundaries, and also that metro, while keeping accurate time internally, only emitted bangs at block boundaries. Not so!

I have done a little more experimenting ...

If I use [block~ 128] or [block~ 256], the vline~ will start up to 127 or 255 samples after the tabwrite~ starts, as predicted by your explanation.

If, however, I go lower using [block~ 32] etc, some really weird stuff starts to happen. The vline~ sometimes starts before the tabwrite~, and the vline~ is no longer accurate ... sometimes it ramps up past the target value of 1 and then drops back to 1. The same things happen if I try [block~ 1] as alexandros suggested.

Unless there's some way to line the message triggering the vline~ up with a block boundary to keep it in sync with tabwrite~, the solution seems to be to use [line~] with [block~ 1].

Thanks again!

If, however, I go lower using [block~ 32] etc, some really weird stuff starts to happen.

This is a bug in [vline~] that's been around for a while. It doesn't work correctly with block sizes below 64. This is actually the case for several objects that use messages but rely on the DSP clock. [bang~] and [edge~], for example, also don't work right.

Unless there's some way to line the message triggering the vline~ up with a block boundary to keep it in sync with tabwrite~, the solution seems to be to use [line~] with [block~ 1].

If you want to avoid [block~ 1], have a look at [cyclone/poke~]. It allows you to set the recording index with an audio signal, so you can sync it up with [vline~].