@lacuna said:

click bang [o] (GUI always on block-boundary) > [spigot] opens > [bang~] bangs > [spigot] closes > [vline~] starts (still on same block-boundary).

Yes, this is how I was hoping it would work, but it's not always the case that [bang~] bangs after the spigot is open within the same control block. It appears to bang afterward if there is a direct bang from a GUI element, but bangs before if the bang came from a delay. (Edit: I'm going to start a new topic on this, I don't see why this should be true)
bang~ runs last.pd
bang~ runs first.pd
If it runs before, then we are really waiting until it bangs at the end of the next audio block. (BTW, you can modify the number of blocks of delay and see the numbers change as you'd expect)

You use [rpole~ 1] as sample-counter, right? But [snapshot~] only snapshots on block-boundaries.

Yes, but all I'm concluding from that is that the message is available in the control block before the audio block that contains its actual time. The fact that so many Pd objects ignore the fractional block of time remaining suggests to me that it could be possible to truncate that fractional block of time in the message in order to make objects like vline~ start at the beginning of the audio block, like sig~.

So is it correct that you want to move the start of vline~ 'backward' ? To the start of the block?

Your diagram annotation is correct, but "want" is a strong word . Let's just say I'm curious if it's possible. Right now, I'm delaying things like [sig~] to match [vline~] by inserting [vline~] just before them. I could have used any of our 3 quantizers to align the first [vline~] ramp with the block following the block that contains the fractional block timed message, but then I would have had to also delay my [sig~] processing a block as @seb-harmonik-ar confirmed.

The last two slides in that PP deck you linked to shows what I mean. Objects like [vline~] implement the ideal, but I'm wondering how to make it behave more like the last slide. See how the message's timing is labeled "t0+16"? Wouldn't it be possible just to zero out the "16" part?

@whale-av I think I answered some of your questions in my previous reply to @lacuna, so let me ask you to clarify what you meant by tabwrite~ vs print~. I think the following test shows they're exactly the same:
tabwrite~ vs print~.pd

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

@lacuna said:

I am highly interested in how to sync or interface Reaper or other DAW with PD control rate sample-accurately intra-blocks.

The second part of this video is about my approach to that.

hjh

@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 I just discovered that if you give vline~ negative delay time value it clears the scheduled ramps and immediately jumps to the value

so if you use a negative delay time in a vline~ message it will start at the same time as a sig~ one, at the beginning of the block
it will only work for jumps and not ramps I think, but sig~ only does jumps..
edit: created a pddp issue to add to the docs: https://github.com/pure-data/pddp/issues/267

@seb-harmonik.ar Like this?

It looks like the second ramp (jump in this case) is still timed relative to halfway through the block though.

@jameslo said:

It looks like the second ramp (jump in this case) is still timed relative to halfway through the block though.

yes that one doesn't have negative delay and the first message cleared the queue already so that one gets processed normally
edit: it isn't relative to the start of the block, but if you're trying to sync with block-synced objects that would be an issue regardless

Hi, I'm simply lost with so many messages. Can I ask someone to explain me why not just use [line~] if you want to be bound by block boundaries? That was my suggestion. I mean, what is the use case of trying to make [vline~] behave like [line~]?

And, well, we now also discovered a hidden and obscure feature of negative delay schedule times in [vline~], but they don't seem to account for any real world use case yet and I wonder if it is actually bugged...