Scriptnode - External Display Buffer when plugin bypassed

[Christoph Hart]

@Dan-Korneff oh then maybe the watchdog interval is set too low. What buffer size and sample rate are you using?

[Dan Korneff]

@Christoph-Hart 96K 512

[Christoph Hart]

This is what I'm seeing when the plugin is enabled and just sitting idle:

Ah you mean HISE as a plugin? I haven't checked that - I just tested the bypass simulator in the HISE controller and as compiled plugin.

Does it still fire if you switch to 44.1Khz?

[Dan Korneff]

@Christoph-Hart I'm sorry for not being clear. I'm talking about HISE standalone. When I refer to enable/disable plugin, I meant via "bypass simulator" in the HISE controller.

[Dan Korneff]

@Christoph-Hart Just a quick update. This may be having adverse effects on the display buffer when the exported plugin is active. I can't recreate it here yet, but I'll report my findings as soon as I can.

[Dan Korneff]

@Christoph-Hart OK. Figured out a clue. It's not playing nice with low buffer sizes and can be recreated in HISE. Same goes for the latest version of Reaper
Anything below 128 will make the meters flicker. Higher buffer sizes work as expected.
Are you able to see the same on your end?

[Dan Korneff]

@Christoph-Hart said in Scriptnode - External Display Buffer when plugin bypassed:

oh then maybe the watchdog interval is set too low

I think this is the issue. Whenever the console reports that the plugin is bypassed, my script kicks in and kills the meter. Where can I find this interval to test?

[Dan Korneff]

@Christoph-Hart

[Christoph Hart]

@Dan-Korneff Just checked with 64 samples here and it works correctly in HISE (the detection does factor in the buffer size). You can play around with the numbers here:

HISE/hi_core/hi_core/MainController.cpp at 0b1d1512d4af43232e44d60f62d072c8e621d531 · christophhart/HISE

The open source framework for sample based instruments - HISE/hi_core/hi_core/MainController.cpp at 0b1d1512d4af43232e44d60f62d072c8e621d531 · christophhart/HISE

GitHub (github.com)

If you manage to find a better value, let me know :)

[Dan Korneff]

@Christoph-Hart After doing a bunch of testing, I've found that the magic number appears to be 48.
When I do the math:

auto numSamples = (double)getMainController()->getOriginalBufferSize();
auto sampleRate = (double)getMainController()->getOriginalSamplerate();
auto blockLengthSeconds = numSamples / sampleRate;
auto deltaForBypassDetection = roundToInt(1000.0 * 48.0 * blockLengthSeconds);

buffer = 64
sample rate = 48000

1000 * 48 * blockLengthSeconds = 64

Is it a coincidence that the magic number is equal to the buffer size of my audio card or that the value is a multiple of my sample rate?

Now the part that is driving me crazy....
Even with the increased sampling time, I can get the transport handler to trigger false positives when I move an item on my screen. Check out the console:

It appears to not only be affected by the buffer, but also the way getApproximateMillisecondCounter is being calculated.