Scriptnode - External Display Buffer when plugin bypassed
-
I'm using a core.peak node with External Display Buffer to draw some meters. When the exported plugin is bypassed, the Display Buffer seems to just loop until the plugin is enabled again.
Is there something that can be done to empty the buffer if the plug is bypassed?
HiseSnippet 2209.3oc6Y0rbaibDFPRX2kb2rU7l8PNNEqb.xQ+PJoXIGEsq9ghNpBoLKQEUYKWNpFBLjbVM.CJfgRh6V9dtjGf8VdMxM+HjGk7Fjz8L.Df+XsxrRbsopfprMwLcO82zyW2S2vsikdrjDYrkcoKGEwrr+LmNiBUCNY.kGZcVcK6O2oESwhIGOJhljXY9Gluks8xu.kwtzJV5m+4WeLUPC8X4CYYckj6wZxC3p7Qae3efKDMn9rK4AEjdmCOySFdhTHGB3YYmpVQTuan8YmSQwVxwx9iN0mqjwcTTEKwxdkik9i5LPdWnQ9q3I7tBF9RMqNvBYFtgT3iHFG05jAbge6r8chkksS6buvxFuvW5zh6yGOdt23mqmfjqQQ+g8RSBukm.d0JBupEf2bfjcAHshAROwoiWLORkOChmO04rP3zoGEb6EghQVqk9qkbNQBRDp1HfdCqQL7xXMbeV0pqQf+Z08KWFb8IJxszXxYgsYzazm5MfCpljCHYqQel5DYPjLDdwsxzBVIecDROw0BZuB55Ey.2RSoGUzTJu4nP+FLlvE0YyMIGOrWOVbB9yFLk2.Bk3yShDzQc0yPR.VgGiDyfWX.KinjD0.Fodm1jPl5NY7ME1C9cAKqYxHlqaVIiM5nWH2JQYXuRJDdASoWwd7XXUpvtGlKjJpPpWDHELhHBLhe2YrfK3PKUZyMErdJBZFRppnU5jZkzskfE1WMnrHZiDl5BdXeyR.mxQrXEmk398kIjJlQapEtxukTq5V6rFg.KmKsqbnhr01AIqhBd9v.fsFFxDInbkeSgMGcVuWiyZ7R3GTEA1VJfkmnG9VpXHKYBNQSXyXPAroA3Ba5KXT+zcbpURTiD7uioWiDA2G1yYLgMhY84IHUYXnmhKCcq3GSu6BohFOpiV1JqQ5kMY+0Hxte6pk+9xfijbE5K.hCoIOjQZxtkIHlzRHwqbIBuGwEjeCEbpQN3.RkwLSTUTnJqR.4HjRvJVpDtmnvFA0gBDy8gAgI060tRkRFbIrRAz397PPrpEmWMf6cSHDCBSr09kJLysfshjIoqq1IdtLNfh9D+8AgPSi+oOdZ+hXpOGhLPz49JTCthEXx+s0ZDHzj9pses1OTXlZimgrdAnrNvDfwVe7Hq9zTz7ZjLlZ0dfotPNLDRGdAySQC6KXtuJa8dJwsFrPyA6qhRr0qSkCj4GSdPzpEraBl2.Q+3CIyqHsoDFpPpCbAx.YL+6PdnfHfC5DbtdxXWN3QqsOgS9cYab8aG.+4WS1dUTL8oZ1ND1ZtuBbTbCrA4A+YMvQfB8F.SjRuYbjwQII79gZJqN4DAyNQfzSDL+TVfhgglTd5bd3ValbZYb9TKfZXnqESyV+zSN5at9hit7zqwUBYYarmVgSFFCAoJxUlnvM2jGFMTUFUxaXLFJB7+lsxUqpVM71zXxITgnKbuYAKopARcZHPkYoYg0h9xteK5nPPppg6C8nY56NNTDCBKiggqO4SKo+PAKEkqO+mxkxxdLAjKlNAyjzh1OjqF5ybAt3DSZxOp4Iy..8SyVo92GAZJ.HLs7TfpEEtsHfdu6jvcsofuFKX9l4rHe0rGPqN2yrY0E3lPNa1bj9oGLMWY9di5LOdWfwBW3Bg9IvQGY8G5ASGMCvRoI3UZlkKogLFKzqA0CJswc18GjW6cc3nWSSd5G3.YdgT5iQ2osTorGLqgI.FYtvMHFtKTPCNVFykHCOWpXuzPgAEJSldpd8l6bXMKwRg.uYaNSaL1Cnna3vftr30LWjNVPnXtIqPz4cWgXwBX8LkPUPPY3YP.yKiXguqxZsRq6BqlLEUfnJcsjedZsjljZVbnjwuvY5iAKM1yKO+adq0e7r5TEMaEgEOuLEXr5ragh8MUqVxoNK4FkLRKaZEiPQruO1+9bayObT9K+4Cui6qFjOv4GNfw6OHuEiCiNDuiwx9W3LSc.Vc6WrEi7KVwde1YqmuyyqVa2mU0J+RJyD6tWsmWs5dE0XqTU1d281c6mukUPw1g9p2BoRJ1JTfzO0wniqrfZgh5.WVlJye6G9g+9WGv88Er1xDNxmx0t5aSfzgbX8bbH9GC8PMS+APmIXFPpZx1UvP2zIvUrXOBXe.gfkFUrGt+i0CyiEhOwoMGp2e9Xbo4fQf98eCLl142Oy4T3dGOUN.Wwowe5CPadNF6WNMz.roo+twsoLAFfx7mnkCLWhsMriRa7y9u3jmVJJlEAE4dorMHuaBMHRvt.v9ZjtPkJ2fjvYykEYf1wnDtdosTrHo79nGs2p1CeXAEtpfFjfqoi0QBfOvzKWVCOnOXILym48p36HeoCKzW+x+BdRmr1XGFLYsrIySZZctomR8wT5usr+X7LABgMtdqqLWyBi6.EgsQUqiDB4cX9NdJWFNpzi0VJFEMPFx8vgLRjg6iBfJxUYf+2SStjxEH4uyvDHAu+KC6.Bq+vJ.4y9bcdDGy8wiZSwLgOwIs8MnhIuwL2bflScPeKtBYo1LdH.PA5Dz3GYYYbdy91XJbsJ6XJXomxZBK+ofkiYafS99YkUPmffce1MJSQmmdD38yf1VtOkczlFSCvnhzn3ragrrxSjbIz8FSoE3cIsNBDeCxurDtM+LmyRxZ1z5JyEfvwxhbwWwjKehYxO14bIOgoOb9ByugFygCMLkXsG3aq8OdreasnG82Vyd4G5aoUaA+VZq7Stuk1+CbU4D2CTJCic3X7woPs7BfqkxYpy5QGJTYiNImokLTlkjImlbACxW1uOFBki84tgNRofF+xG4KO7BlfQSJvi9UGheAFZbKSwLKhun168m9btmW+RGCbIHQm7+Kw4mlk37A4R6OD1Hf5EKu1yTqCxS+D8Hv9NT++NQImV36jZS21DT3Ojk6ZOuIWpYTbqEUwsWTE2YQU72rnJ9rEUwcWTE26GWQ7RniFpjAlPSnBh1mpus219zPJvx0QDV+az2FsBA
Since the project contains a ScriptFX, here's the full project:
http://tinyurl.com/mr3zcsh4Any help is greatly appreciated.
-
@Dan-Korneff Same happens here, and this is annoying
-
It's incredibly annoying on systems like Premiere Pro because plug-ins are put into a bypassed state if the transport isn't moving. Pure chaos!
-
@Dan-Korneff I think the best way of addressing that would be to add a callback handler that is fired at a DAW bypass toggle event, then you can just stop the timer that drives the peak meter
-
@Christoph-Hart That would be super awesome
-
@Dan-Korneff Alright, I've added a method to the TransportHandler class that you can attach to bypass changes. The implementation was super annoying because there's no clear API call from the plugin host, so I had to hack something together that works okish:
https://docs.hise.audio/scripting/scripting-api/transporthandler/index.html#setonbypass
But for the task you need it to it should be fine.
-
@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.
-
@Christoph-Hart Never mind. Looks like I just had to trash my DSP binaries
-
works like a charm!
-
@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:
-
@Dan-Korneff oh then maybe the watchdog interval is set too low. What buffer size and sample rate are you using?
-
@Christoph-Hart 96K 512
-
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?
-
@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.
-
@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.
-
@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? -
@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 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:
If you manage to find a better value, let me know :)
-
@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.
-