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?

I don't believe any control-domain time measurement will be 100% accurate. If it's off by a couple milliseconds, that sounds normal.

You could write audio into a file and measure the samples between attacks. That's about as good as it's going to get.

hjh

@raynovich I ran this test and you can see that all the delays are rounded to the nearest 6 ms or so:
delayInRealtime.pd
I was expecting it to round to the nearest 1.45 ms because I assumed that bangs would be processed between 64 sample audio blocks, so something else is going on.

I found what I think is the delay object in x-time.c, but I don't understand the code structure well enough (yet!) to make heads or tails of it.

@jameslo Not sure why.
There will be some computational and OS latency too. So I don't get exactly the same graph as you.
And in 32-bit Pd it is all over the shop...... so maybe some bit dropping.
And when is the bang processed by [realtime].....? I would expect that if [delay] cannot be zero then [realtime] cannot report accurately either.
David.

@raynovich Here is a thread about this phenomena: https://forum.pdpatchrepo.info/topic/10900/delay-0-and-pipe-0/17

Thanks all for what you did. This has become a concern of mine as I look more and more into granular synthesis and sound design. As you all know, a digital click can so easily be created in a patch. Given this little discrepancy, I am a bit surprised digital clicks do not happen more often.

I am though wondering if the sound design delays are not impacted by this because of the constant flow of sound from a delay line?

I wonder if [realtime] is just measuring something irrelevant to sound output, e.g. when the OS and Pd decide to schedule computations. That would explain why my and David's results for my previous test differ. Look at these tests:
delayInReality.pd
Neither jitter in the 6 ms range, and they only transition on 64 sample boundaries, which is what I'd expect because that's when control-rate messages are processed (assuming [block~ 64]).

edit: ugh, I just realized how bad my sends and receives are. Things still work, it's just terrible coding. Just run one side or the other.

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