this one's because reduced has an optional y parameter. Not using it results in a warning:

@dannytaurus Just throwing this in the case it might be related, I reckon there was a preprocessor for the filter or EQ to use the SVF, so perhaps something to check if Hise is in a certain state and compiled plugin in another

@shashwatshukla then it's not on your side and pitch module is broken. You're stuck until it's fixed.

@shashwatshukla Have you tried to compile the most basic empty network first before filling it with nodes?

@dannytaurus said in Claude screenshot crashes Hise:

so I don't think the recent commits introduced it, they just make the message thread busier so the 1 s timeout trips more often.

Yes that's it, in fact it was crashing less before for the mere reason that the project I am working on at the moment is way bigger. UI takes long time to recompile, that's the trigger...

So in the end it just needs 2-3000 sec timeout, should be enough for most cases...

I'll test and make a PR when I have a minute

@David-Healey When Claude makes modifications on UI, it makes a screenshot using the interaction test window to see if it renders as it should

@Christoph-Hart Seems to happen a lot more since the last commits

CLAUDE:

HISE 4.9.3 (102de5c4) — recurrent SIGABRT via the REST API screenshot endpoints

Symptom. HISE dies with Abort trap: 6.
8 of the 33 crash reports on this machine (2026‑08‑19 → 2026‑08‑23) have byte‑identical stacks:

std::terminate() → juce::MessageQueue::runLoopSourceCallback(void*)
  → __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ → …

i.e. something escapes a MessageManager::callAsync callback. The stack is already unwound, so the report names no culprit — which is why this has been hard to pin down.

Correlation. Every occurrence I could attribute happened during GET /api/testing/screenshot. Two crashes today were directly on that call; two earlier sessions logged 500 — /api/testing/screenshot?moduleId=Interface&outputPath=… shortly before dying. It hits both the cropped (&id=) and the plain moduleId‑only form.

Root cause (hi_backend/backend/ai_tools/RestHelpers.cpp:2539).

SafeAsyncCall::callAsyncIfNotOnMessageThread<...>(*sp, [&](...)   // fire-and-forget
{
    hise::ScriptContentComponent component(&spp);
    capturedImage = component.createComponentSnapshot(cropBounds, true, scale);
    captureSuccess = capturedImage.isValid();
    captureComplete.signal();
});

if (!captureComplete.wait(1000))
    return req->fail(500, "screenshot capture timed out");   // ← stack frame dies here

callAsyncIfNotOnMessageThread is MessageManager::callAsync (MiscToolClasses.h:87) — it does not wait. The lambda captures capturedImage, captureSuccess and captureComplete by reference off the REST thread's stack. When the message thread takes longer than 1000 ms, the handler returns, that frame is destroyed, and the lambda then writes into freed stack memory and signals a destroyed WaitableEvent. Hence: 500 first, abort shortly after.

1000 ms is easy to blow — the lambda constructs a fresh ScriptContentComponent and paints every script component, including all custom paint routines, on a 1600×900 interface.

Same pattern, two more sites: RestHelpers.cpp:2725 (testing/e2e, 30 s) and :6508 (dsp/screenshot, 1500 ms — and that lambda spends 500 ms in runDispatchLoopUntil before capturing, re-entering the message loop).

Suggested fix. SafeAsyncCall::callAsyncAndWait already exists in the same header (MiscToolClasses.h:104) and is documented to return false on timeout/deletion. Failing that: heap‑allocate the shared state in a ReferenceCountedObject/shared_ptr captured by value, so a timed‑out request cannot outlive it. A try/catch around the lambda body would also convert the abort into a 500.

---

Two caveats so you can present it accurately: the other 5 SIGABRTs I can't attribute to the screenshot endpoint from the crash file alone — the unwound stack gives nothing. And the dangling-frame mechanism is provable from the code and matches the 500-then-crash sequence, but I couldn't confirm which exception actually terminates, only that one escapes a message-thread callback.

@dannytaurus I've used freshdesk and was very happy with it, but after a year the trial period ended...

So I've made my own ticket support system. Seemed good at first but many people, once they get notified by email for a response, instead of clicking the link in the email they just respond from there, killing the purpose and making it messy...

Not getting a lot of tickets that being said, so it's ok for now... But when i'll be ready to pay 200€/year I'll go back to freshdesk, until then I'm opened to any cheap yet reliable solution too

@Christoph-Hart So it appears the cable manager can only receive global cable data but not simple values... Is it a missed one or on purpose?

@dannytaurus Oh you were faster, I've just made the fix too...

It's always been activated in my settings but it never does what it promises... I have to toggle it manually each time I restart Hise...

Perhaps I need to add it in the XML manually in the case it somehow misses it?
I don't want to ruin the entire XML by just deleting it so...

@Morphoice I think you'll need to store the base64 state of the module in question in the preLoadCallback and restore it in the post CB.

But I'm afraid continuous sounding reverb isn't possible, because the audio engine cuts during preset change. And I remember @Christoph-Hart saying it's not possible to change this because it would cause too many race condition issues during the switch phase...

Unless...

You run your own preset system which would only perform parameter value changes... Like undo/redo, AB comparison, or random buttons generally do...

I just wanted a quick shout-out after having an amazing talk with Arnar (@lalalandsynth)
It's not just about the design, it's the whole process of getting involved in the final result for the end user that drives this guy!
Great ideas, new implementations, the experience talks...
I can feel already my prototype will reach a quality I wasn't expecting! I knew the design would be excellent just seeing the examples above, no doubt. But trust me the design is just a part of the job he can do...
So thanks Arnar to be this very kind person who knows his stuff, I can say I've found my designer...

@Lindon this one uses an impulse. See if you can make it work with your project, then you might need to use a noise and a correlation algorithm later instead of simple subtraction of the peak index

Note that it takes the number of channels of the routing matrix.
the current snippet gives you a report of ch0-1 delay L-R, and ch2-3 scriptFX, which is L=silent and R=untouched. A silence gives a negative latency that easily speaks for "there's nothing to report"

HiseSnippet 2567.3oc6Z80baabDGTxvNjwsSbl9Pm9zE9RghnoHnUbriicknDUrlZJwgj1Mc73ndD3n3YAdfE.zRrc7646Wm9snOzuAs6d2g+QBZIqX2LYlRayg31a++d68aIc2.eGVXnefQoJClOkYT51l8mKhFu2XJWXb39Fk9Lyms6f1Gs2e9jCN7n8a2yn07ozvPlqQoRq+c3tJU9FFxW+6+PKpGU3vRWxv3E9bG1y3S3Qoq1cm+H2y6.pKa.eRlcu8NG53K1y2yeFXQqa1vXJ04L5orin31Vyz3ozvwFk9RyG533LZ6sG0z1Ya6sev8G9PamQNCa17gM9Z2lL2g2eHi8vGLxnzMa6xi7C5GQiXgFktQKe248G6etPofWvC4C8X3C1F8AMqV9.eOWzEwUM1aL2ysabnJz.jR2z.25p.2uwrC2kmrd1.HRfjxQ1.Xo0xadqmy7ryZdMxXdEXRkxXR2PYR2wruS.eZTJEzd9TyCEQrfQTHOk0TT60Xs+UEy87gcHhpOgdF6f.3gDNrteiF0Hvaa7nJvtB88X0c7Xz.KXgJUDPdJDxYLR9hlJ+cfHeDw5K3g6yFwELWqSOY3rQiXAgarQY30od9CodjjUIOl7xW8nkYJfQc4hSaI2UeOn3B3Og4koBxoQghwwO3cJnkouBQMzy24r97+FS5Ho9Q7x.asEmBat9orHs3fkwHVgdWOlygBW1E4EWVJfDuqMFugSKgQj2PCH8GrauAmjOpeRqAGAaMNaRccaMKJxWXUcU6tZMBjdwj6p1Q8PVjUUdXG+IfLoAyAVhBlwvzep0DyW6NGNXP6dfQH6pfAfd9yhfvZGZT.+BqpKrypfbREyQOuyI68zcQmXg8gR5nYS1mEBBiFwgtFioBAyKzJukDkF8cfPXjriSvwCeMyIRUyBElBOfNYzLgCJIxz.1TZ.Skp.ABUukgjIjF7ErVzfcira1X3zI4Rr8oSl5w5AZvZCxWRZ9nJkqTdje.wh+3FOhv+1XmA97latQkxfPKmTs+R9qTE7js1hvnNiIUcTNTUxXnWTHI5behdyPFhvgUFyHLnuJbzrFwNdEnvkweCK.jN7WoA7Zz.d821DdSpYopyo6W9ZT8JGVGmrx6qaHsrlgLGf22pDdNIz3UuLOGasMJyF0+JkOoLTxXZHgRt68baQlBkAjo9gbLnCk+PzkLDTMoYEPCusxhoAYxBD0ehxwJHB5aZOVcTkDAgHFwErCBU3RTNBnNPP9AQUhvhWY9eOpm2P3pEq3btJIiGGW7jFdTSmsha3MMfKfCAOItnjnNdP50t6w8F7MXMbZvGRkbQZasjvOVbxcwixIzpyQUd7HfGoHj6wCbAgy7CEpBLX+Nieo8qh2aWF8Lnf6t3pMVd0LsgVVhcByUA2AtSl2GBlB2vCfqjj5KzZACPYY3+fTgi+LQDQ1wOTlOnDAlAinvkVj2vYmWi75YvQwgLG5rPF4bFwgJpWudrwbJcJXD1MRrt2P8lwjc+gnSshbqZEEApk0UqsXT6UIhWaqpKWzNR1SoJ0W2iINMZb7QUcJK09dljLHEn.MjA2NZg9wcIVUqR1T6BvghMzxQEyz52AXqZU0Jx2xdFMizSNsBuPt1DXijkOkqn5b.aPR4sw9DpKUYOptmP16oeCvd4xaJK5jBcScv.BvjMU5oLoZ2CO56h2ZQ0TorYmksds2KCW1qlqlY4pU+XlxdeYVa6dY2t97ljmMW5jQFt1NKWcRTRlJ+jje9C0pPlLeoaxEMlGVOLxeprwA1EBaNkzLB.tAg37sglpvasz8J9hUcqJdEcfumki+joP2KQTMUQTRWI8Sx5PnMFpTk8XKghg8hW.fPCkg9tuIWq2j1gWpEpuwDe8VrsdanMa9MSRv.VI8UlPvQ9Qri08agl7jEIMZTgzz52CSAEPVmbVMiVhYSFhWTlFWwMBXkyC.2b0.vyNefiBSUlM5KNTviNdJSrpoFLz.wPv5ZqB1ZjDp9uVCUWAPyfCHx+clqJWXH8grCYY77C2mFQikLnDPwSYAQbzmJsO6M.7U0PAkMAPSmA0yx8pK2LJcqqicbADuJgped7Gx.LDWBW6btaz3TiUryXF+zwYlF7G1wX4YWfol7cmAGXyOJENvol.jdyM+BNih..SLO6.oevlu5pZh2wrKOxYbw13ZEXiPN6igMpmJ8WY1FfV3DkZf2v7fu+izHn2X4XTEc8DnSUzYAb7ENA5uecyk.iOvuqGctUXBJ6Zjz4tV5XutCbKbGVZfzgqBh2WjAhmBlOzqPi9AZjBSpLt9DtHQN3chp60qkhcCw+lrtD3UtQ4zHBwNlS.jv.NID8adLho14RPDiIsDBQEP9Bm5UilOfAuOv2JCXc2KPas1B1XsLtcpv4irxFMdbgyXGCyIEojDa3z45KFg8A26xHgRSCPoiKq8IUZTxTgNxSdBryTrMPPfkpFU5JrHucYQImscQeTCkZA0jLfStBE.AVJ65LZA0SO4wqnrHynWELMuTq3bOuGWdYdkO5Z+t6bjapbn4DLace+YANr3wpwt4XGK8yMha32mIbkO7efWZh1ws9Qh1KPrI97ZZhMWf38vmWWS7dwDSu37ZcOW11heph3s.hP6DYOoOQ8Y6bshjKgfJdFaTlqp9s6jPnWlKw9KO+eFsyALlKBhJOGFFwq2K+sdFFOy+7tfBOHf8WSV9G+G67T9RqZr+Ncjokj60Fvfat6OW3j6hj0+EZ4.97JKGhIlVNboWyba8ijC9d6htgozO9w6Bl2S3m27m0TVbrsvTVLwOrmfOhEctevYxuxZ8mgyfprVnL8bxnK.GGZdhnmfipMpC+wXWOO+yQ.qbMtJHcJWqqu27oi8EbGbI0Nhc5cmfeAEw1aJnrVwY1351mRCGP4dHFs9yBAP7tGK5CxQ9iYfXjNx2E9zMOf5.Yq4coHj16XhiA..qvuzrD.V4bizhOLso9YLxsATtw+fGJSA7fIRH4qYBbgzUwJkAfZ3VlSl4EwMVownHWjtiY8pp10xoV42zed0dayIH9HEkh0nh1knw05RCf8Gwz+XFwOAatCW7B0.OlXsfQG5EIOaCOqrM0R4139rQTvayslQlKLLLx6cxT3kjgWgKJocECpFYc0b1i7GwAeBlOXMUszggu.oBvbh8MnTdkB3mtna46e1Dp774O4KaKt47mmLCPu16cbu8WwP.V+BcH.6e9FBnvewp28X.1W2w.bFWHnekQrL99XP+KLKfjMvwAz2E6.u2.+cFeYv7uDE813jzU.7+VacEf+amB+eqsz1+RRWMB.RWOD.4+OEvG3o.9eryY7tbtRK4bSnNA9m3nxzX+5OQtBjpDx6XJa1AelXu7W92DtK+DGm7hZIFadcY7dWWF295x3WccY79WWF+5qKiO3xYD+e+wtyh7mnfsBvP61VV9VpTaA96jIu1y3+BPu2HsI

@Lindon I'll try to find and recycle something...

@Chazrox I contacted you on discord since I have issues at multiple places with account verification and password reset, confirmation code, etc...
It doesn't seem resolved at the very moment I am writing this

@dannytaurus said in Measuring plugin delay times....:

This might end up being the biggest issue of all

Not really because this would be poor design to report dynamic latency anyway.
The way (one way?) to do it is to report for the maximum latency, and add a delay in the chain based on the difference between the maximum and the currently loaded FXs. This is the purpose of having a latency array per FX.
So the host sees a permanent latency, and it's the plugin job to compensate for exceeding reported latency.

@Lindon My process is to automate this from Hise itself.

You can write a test script that:

• loads the FXs one by one
• play a test signal
• record that test signal before and after the FX in 2 scriptFX module process callbacks (or 1 unique recorder with 2 passes, bypassed/unbypassed)
• perform a cross correlation between the two buffers to get the sample diff
• and populate an array that will hold the latencies per FX

Claude can easily create this for you if you need

And as @griffinboy said group delay can be tricky and give weird results, especially with impulses. I'd do it with white noise since cross-correlation is very effective with it (I do this in my Align-IT app)

@Kalliopei it depends on what you want to achieve.
If you want to draw the buffer you need to expose its display buffer (as you did already since the little icon is green), get a reference in the script and draw it in a panel using a timer.

If you want to get the nodes to performs realtime network modifications, you'll lose the ability to compile the network as DLL (it's one or the other).

And it's not getNode but just get

@Christoph-Hart I was afraid of this but in the end yes, I guess I could. The blocks should just need a global cable so I can have a unique sender network for all the cables and then make a module per FX receiver... And it'd probably simplify things a lot instead of having just one giant blob... Should have just have thought about that earlier!