Check Latency broken on latest develop build?

[dannytaurus]

@David-Healey I defer to @ustk's vastly more detailed knowledge here

[ustk]

@dannytaurus That being said, it only matters in a parallel track mixing context (but nowadays it's still very frequent, we parallel this and that everywhere...), but you don't mind such a small latency for instruments...

[dannytaurus]

@ustk Dug into this and found the root cause. Two PRs are up that fix it:

• https://github.com/christophhart/HISE/pull/1013
• https://github.com/christophhart/HISE/pull/1014

What broke: since e429f19d1 (Jan 11) the IDE builds with a 16-channel configuration, which disables FORCE_INPUT_CHANNELS - and with it, the path that carries the input buffer into the signal chain. The latency check injects its test impulse into that buffer, so the impulse never came back: no result popup until you play a note, and then the number is just the elapsed time. a6c5d9dd7 fixed an include-order problem in the same area but the input path is still compiled out in the stock build, which is why the tool stayed broken. PR #1013 keeps the input alive during a measurement (no-op the rest of the time, backend only).

Second problem: even with the signal path restored, the old single-sample impulse can't survive effects that smear transients. Something like pitch_shift spreads those two samples over its whole analysis window and the output peak lands ~50x below the detection threshold, so the check hangs forever. Following @ustk's suggestion, PR #1014 swaps the impulse for a 20ms sine burst at 1kHz and reports the onset (first threshold crossing) instead of the peak. It also adds a 2 second timeout with an explicit "no signal detected" error instead of waiting indefinitely.

Test results with both fixes (48kHz, stock standalone build):

• fully wet 333ms delay: 16000 samples, exact and repeatable
• convolution reverb: deterministic result that measures the onset of your IR (the convolver head itself is zero latency, so silence at the start of the IR file is what you're seeing)
• pitch_shift: now reports (~4200 samples); the remaining +-250 sample spread between runs is the stretcher's own timing indeterminacy, not the measurement

One side discovery while testing: wrapping pitch_shift in an oversample4 node cuts its real-world latency roughly 4x (~88ms down to ~23ms), because the stretcher window is sized in samples, not milliseconds. Costs you the CPU of running it at 4x rate, but useful if the latency matters.

[dannytaurus]

@ustk As per @Christoph-Hart 's suggestion, updated the PR to use a noise burst instead of sine burst.

Re-ran tests and it all checks out.

https://github.com/christophhart/HISE/pull/1014