This sentence in timer-help helped me find a bug in one of my envelope generators made with [vline~]:

I was wondering why [timer] sometimes returned fractions when set to [tempo 64 samp(--now I know. But hold on--bangs are only processed between audio blocks, so that implies that the bang must carry with it some attribute that indicates its actual timing, one which might be within the next audio block.

Awright, then maybe [vline~], being all sophisticated and stuff, takes a peak at that attribute? Holy smokes, yes it does:

So my mistake was assuming that [vline~] always started at block boundaries, and that made it misaligned with other audio processing that was initiated at block boundaries. How have folks dealt with this? I suppose I could look for a way to use [vline~] to potentially delay the other audio processing. Is there a way to zero out that bang timing attribute, so that the bangs are quantized to block boundaries? Or some other way to force [vline~] to start at the beginning of the next audio block?

Edit: it's not just bangs that have that intra-block timing attribute--you can see in my example that it's preserved through the message that's sent to [vline~]

@jameslo this is getting a bit off-topic but it looks like portmidi does have timestamp info on received messages, but afaict PD doesn't use it

@jameslo said:

Is there a way to zero out that bang timing attribute, so that the bangs are quantized to block boundaries? Or some other way to force [vline~] to start at the beginning of the next audio block?

Like this?
vline~onnextblockboundary.pd

Edit: it's not just bangs that have that intra-block timing attribute--you can see in my example that it's preserved through the message that's sent to [vline~]

As far as I understand it now, some objects
([metro] [del] [pipe] [vline~] maybe[vsnapshot~])
do intra-block-messaging/banging and some won't (like [tabwrite~] in my patch).

The scheduler processes GUI and Midi i/o at block-boundaries.

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

@lacuna Nice! I think this has the same outcome as @seb-harmonik.ar's external, which is to delay the timing to the next block after the intra-block time. I was hoping to anticipate, i.e. move the timing forward to when the message is processed. Look at my version of your thing:

The snapshots at the bottom show that the bang is processed at the beginning of the 2nd block, even though it is actually timed to the middle of the 2nd block. It's at the beginning of the 2nd block where my other non-vline~ audio processing happens, and that's the stuff I was hoping to synchronize with.

I should warn folks that I managed to use vline~ to delay my other audio processing and so my practical problem has been solved. I'm just continuing this discussion because it's interesting.

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

@whale-av said:

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

Yep, I think that's it, so let me list some of the ways I don't understand things
[1] Not reading the documentation
[2] Not understanding the documentation I've read
[3] Forgetting what I used to understand

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

Man, this got me excited because the only reason my bang quantizer outputs where it does and not one block earlier is because [bang~] for the end of the first block has already executed by the time my spigot opens and so we have to wait for the next audio block to complete. I was hoping [delay 0] would cause the bang from [bang~] to be rescheduled after my spigot opens, but it doesn't appear to.

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

@jameslo said:

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

Man, this got me excited because the only reason my bang quantizer outputs where it does and not one block earlier is because [bang~] for the end of the first block has already executed by the time my spigot opens and so we have to wait for the next audio block to complete. I was hoping [delay 0] would cause the bang from [bang~] to be rescheduled after my spigot opens, but it doesn't appear to.

That works, screenshot when left bang is clicked:

vline~blockquantizer.pd

(thought [bang~] would be expensive, that's why I [switch~]ed it in the other patch.)

@lacuna The left bang is not the issue because UI clicks are always block-aligned (I think). It's the right bang I'm trying to anticipate. The bang out of [del 1] is processed at the beginning of the first block, but it has a timing attribute that says it's 1 ms into the first block. block-quantizer still delays it to the beginning of the 2nd block.

Edit: oh wait, did I miss your point?

@jameslo Thought that's what you where looking for? 'block-quatizer'?
But you want to move the output of [del 1] back to the start of the block?
Interesting, but I think moving backward is not possible in realtime Pd ... (hmmm there is the [lrshift~] object for moving in a block... )

Edit: My point was that this quantizes to (next) block boundary, and if already at it, it stays there.
[del 0] Breaks the deterministic order ( [t b b] ect.), as [delay] and [pipe] always do, and moves to the last point after everything else deterministic is processed, but keeps at the same logical time (zero delay).
But what was your point?
Edit: Now I tried without [del 0] and everything is the same. So I completely missed your point??

@lacuna First of all, I honestly don't understand why your left bang works, but let me ignore that temporarily. Using the right bang in your example, here's what I'm asserting:

Similarly, in my first response to you, you can see in the snapshots that the bang from [delay 1.5 64 samp] is being processed during Ctrl 1, 32 samples before its real timing. If I used that same message to, say, set a value into [sig~], that value would take effect immediately in Audio 1. So I'm wondering if there's a way to truncate that fractional block timing without resorting to an external.

So then, WRT your left bang, I think you proved that my theory about when bang~s happen is wrong. But I'm pretty confused about that at this point.

@jameslo For me it is difficult to understand. Maybe I am missing the whole point and all I say is off topic.

First of all, I honestly don't understand why your left bang works

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

Similarly, in my first response to you, you can see in the snapshots that the bang from [delay 1.5 64 samp] is being processed during Ctrl 1, 32 samples before its real timing.

This I don't understand.
You use [rpole~ 1] as sample-counter, right? But [snapshot~] only snapshots on block-boundaries. (That's why there is [vsnapshot~], but that was buggy, when I last tried it.) [snapshot~] shows 64 samples, one whole block.
If you snapshot later, you see [del 1.5 64] outputs bang after 96 samples:

([sig~] also updates its output only on block-boundaries, not within the block.)

@seb-harmonik-ar s [pip~] could be done with [bang~] and [timer], to measure the time that has passed into the block.
Or for signalrate~ output~ with [rpole~ 1], to measure the samples past into the block.

you don't need to predict the future to make it one block earlier

So is it correct that you want to move the start of vline~ 'backward' ? To the start of the block? To the start of that block where [del] outputs later on a message to [vline~]?
Clicking [o] bang at ctrl 0 > [del 1] outputs after 1 ms, where audio 0 is happening > [vline~] should have started before, at the beginning of audio 0 ?
Is this what you want?

Here is a paper where message- vs signal-domain and scheduleing are graphed. It is in German, maybe you can use a translator and the time-graphs on the last pages are english / self-explanatory. And you problably already know all of this.
https://iaem.at/kurse/ss19/iaa/pdscheduler.pdf/view

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

@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