Scriptnode - External Display Buffer when plugin bypassed

[Dan Korneff]

@Christoph-Hart I'm getting a crash loading my project on this commit using the Release version of HISE in ScriptingAPI.cpp

void OpaqueNode::createParameters(ParameterDataList& l)
{
	for (const auto& p : ParameterIterator(*this))
		l.add(p);
}

 	HISE.exe!scriptnode::OpaqueNode::createParameters(juce::Array<scriptnode::parameter::data,juce::DummyCriticalSection,0> & l) Line 101	C++
 	HISE.exe!scriptnode::InterpretedNodeBase<scriptnode::bypass::simple<scriptnode::OpaqueNode>>::postInit() Line 199	C++
 	[Inline Frame] HISE.exe!scriptnode::InterpretedNodeBase<scriptnode::bypass::simple<scriptnode::OpaqueNode>>::initFromDll(scriptnode::dll::FactoryBase * f, int index, bool) Line 191	C++
 	HISE.exe!scriptnode::dll::BackendHostFactory::{ctor}::__l35::<lambda_2>::operator()(scriptnode::DspNetwork * p, juce::ValueTree v) Line 1905	C++
 	[External Code]	
>	[Inline Frame] HISE.exe!std::_Func_class<scriptnode::NodeBase *,scriptnode::DspNetwork *,juce::ValueTree>::operator()(scriptnode::DspNetwork * <_Args_0>, juce::ValueTree) Line 874	C++
 	HISE.exe!scriptnode::NodeFactory::createNode(juce::ValueTree data, bool createPolyIfAvailable) Line 1643	C++
 	HISE.exe!scriptnode::DspNetwork::createFromValueTree(bool createPolyIfAvailable, juce::ValueTree d, bool forceCreate) Line 902	C++
 	HISE.exe!scriptnode::DspNetwork::createFromValueTree(bool createPolyIfAvailable, juce::ValueTree d, bool forceCreate) Line 870	C++
 	HISE.exe!scriptnode::DspNetwork::createFromValueTree(bool createPolyIfAvailable, juce::ValueTree d, bool forceCreate) Line 870	C++
 	HISE.exe!scriptnode::DspNetwork::createFromValueTree(bool createPolyIfAvailable, juce::ValueTree d, bool forceCreate) Line 870	C++
 	HISE.exe!scriptnode::DspNetwork::DspNetwork(hise::ProcessorWithScriptingContent * p, juce::ValueTree data_, bool poly, snex::ExternalDataHolder * dataHolder_) Line 153	C++
 	HISE.exe!scriptnode::DspNetwork::Holder::restoreNetworks(const juce::ValueTree & d) Line 1604	C++
 	HISE.exe!hise::JavascriptProcessor::restoreScript(const juce::ValueTree & v) Line 1615	C++
 	HISE.exe!hise::JavascriptMasterEffect::restoreFromValueTree(const juce::ValueTree & v) Line 821	C++
 	HISE.exe!hise::Processor::restoreFromValueTree(const juce::ValueTree & previouslyExportedProcessorState) Line 177	C++
 	HISE.exe!hise::Processor::restoreFromValueTree(const juce::ValueTree & previouslyExportedProcessorState) Line 177	C++
 	HISE.exe!hise::ModulatorSynth::restoreFromValueTree(const juce::ValueTree & v) Line 147	C++
 	HISE.exe!hise::ModulatorSynthChain::restoreFromValueTree(const juce::ValueTree & v) Line 392	C++
 	HISE.exe!hise::MainController::loadPresetInternal::__l2::<lambda_1>::operator()(hise::Processor *) Line 400	C++
 	HISE.exe!hise::MainController::KillStateHandler::killVoicesAndCall(hise::Processor * p, const std::function<enum hise::SafeFunctionCall::Status __cdecl(hise::Processor *)> & functionToExecuteWhenKilled, hise::MainController::KillStateHandler::TargetThread targetThread) Line 475	C++
 	[Inline Frame] HISE.exe!hise::MainController::loadPresetInternal(const juce::ValueTree &) Line 482	C++
 	HISE.exe!hise::MainController::loadPresetFromValueTree(const juce::ValueTree & v, juce::Component * __formal) Line 355	C++
 	[External Code]	
 	[Inline Frame] HISE.exe!std::_Func_class<enum hise::SafeFunctionCall::Status,hise::Processor *>::operator()(hise::Processor * <_Args_0>) Line 874	C++
 	HISE.exe!hise::SafeFunctionCall::call() Line 550	C++
 	HISE.exe!hise::MainController::SampleManager::PreloadJob::runJob() Line 272	C++
 	HISE.exe!hise::SampleThreadPool::run() Line 140	C++
 	HISE.exe!juce::Thread::threadEntryPoint() Line 96	C++
 	[Inline Frame] HISE.exe!juce::juce_threadEntryPoint(void *) Line 118	C++
 	HISE.exe!juce::threadEntryProc(void * userData) Line 66	C++
 	HISE.exe!thread_start<unsigned int (__cdecl*)(void *),1>(void * const parameter) Line 97	C++
 	[External Code]	

The debug version of HISE can load the project properly.

[Dan Korneff]

@Christoph-Hart Never mind. Looks like I just had to trash my DSP binaries

[Dan Korneff]

works like a charm!

[Dan Korneff]

@Christoph-Hart I am noticing one thing. I made a simple test like this:

const var th = Engine.createTransportHandler();

th.setOnBypass(function(isBypassed)
{
	if(isBypassed)
	{
          Console.print("bypassed");   

	}
	else
	{
          Console.print("running"); 
	}
});

the state of setOnBypass seems to have a mind of it's own. This is what I'm seeing when the plugin is enabled and just sitting idle:

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