Hey all,
I bet there is some thread on this. I was looking at realtime object and wanted to test the delay object. It seems to be off be a few milliseconds. Is this unavoidable? is this related to the blocks that are sent?

@jameslo Yes, this was also the findings of the above mentioned thread. It seems like Pd is accurate, only [realtime] is not...

@ingox But I'm not assuming that [realtime] is inaccurate, I'm just wondering whether it is showing that the OS and Pd are precomputing future logical time events in chunks, i.e. lurching forward faster than logical time. If at real time 0 Pd finished it's first 6 ms of logical time work, then it could go on vacation for 6 ms without anyone in logical time noticing. But the real time folk notice.

I dunno, I'm probably high.

@jameslo Ah well, i don't know either. I should probably get high

But none of this speculation is relevant to @raynovich 's question. Regardless of the reason, [realtime] isn't going to show you the 1.45 ms time quantization that happens when you naively mix control rate and audio rate processing (as demonstrated by my 2nd test). And control-rate delays like [delay] and [pipe] are different from audio delays [delwrite~], [delread~] and [vd~], so I'm not sure what you (@raynovich) are referring to when you write "sound design delays".

@jameslo Sorry for the confusion. I am not the well-versed in the language to be clear. When doing audio processing, a few milliseconds error can cause a digital click. I was worried that the digital processing would be compromised. As I am looking into granular synthesis, it is a bit overwhelming figuring out how to make granular synthesis work without creating lots of problems.

@raynovich said:

When doing audio processing, a few milliseconds error can cause a digital click. I was worried that the digital processing would be compromised. As I am looking into granular synthesis, it is a bit overwhelming figuring out how to make granular synthesis work without creating lots of problems.

Avoiding clicks in granular synthesis is mainly a matter of applying a windowing envelope to every grain. If every grain ramps up from silence and back down to silence, then there is never a sudden transition.

Just the other week, I demonstrated in a class a way to do that: each grain runs a line~ from 0 to 1 and this splits to two places:

1. Map this normalized range onto the desired range of samples to pay back, and tabread4~ the source.

2. Map the normalized range onto another table containing a Hann window, and tabread4~ that.

3. Multiply, and... a clean, windowed grain.

hjh

hjh

@ddw_music Yeah I got that much. I am just commenting.

@raynovich So to sum up.... probably..... if the block is set to 64 then control rate events are going to be processed all at the same logical time between each audio block (in this case every 1.45ms unless scheduled for later).
The audio thread has priority....... so only os window drawing and driver interrupts (Wi-Fi, network etc.) are going to interrupt that thread (clicks due to DPC latency).
Other clicks are due to loss of sync with the soundcard clock (unusual nowadays) or incorrect patching........ sudden jumps in audio level due to incorrect windowing at crossover points....... and output > 1.
[realtime] is as close as you will get to real world time...... but Pd is running in another world.......
Proper help from Pd extended doc.......realtime-help.pd ...... Vanilla help is as useful as a plastic duck.
David.

Thank you all for the thoughts!