Crash in GRID write new

@thetechnobear can you do me a huge favor I hate to ask – but I have tried many things to locate wy my plugin is crashing.

Method to crash:

  1. load plugin, add sample to sample pad, then write new. :confused:

removed timer… and I just cant figure it out… Any help is appreciated. I know your time is valuable.

I might have found the issue – I am using JUCE 7 … 8.12 had the midi issues… you are using 8.06… so I am building with that now

1 Like

yeah, so juce is hit n’ miss, generally its moving forwards,
but it can have regressions esp on linux, and sometimes on mac.

the ‘issue’ with Juce is its now a bit of a sprawling sdk, hitting so many platforms and use-cases, everything from window standalone, to plugins, to mobile apps…
thats a huge surface to get compatibility on , and they fail and fix.

So what I do is…

when im doing larger scale changes, e.g. refactors.

I attempt to upgrade to the latest version, this can be due to external reason e.g. compiler change (clang / macOS sdk break it) ,
but any how, I do this ‘regularly’, so I dont fall too far behind… which makes it more likely its ‘minor changes’ that huge shifts.

But I recognise this can/will break things…
if its breaking changes, then I’ll update my code to the ‘new way’.
if something in juce is not working i will try to workaround.

if I can’t or its just broken, I’ll go thru the juce change list etc, and look to see if I can find where it might have changed… sometime I have to delve into the juce codebase… then go back to that version.

it can be an iterative step, trying different versions ,
if you are unlucky, you also end up having to change your code to reflect api multiple times…

its a pain, hence why I do it at ‘certain points’ of my development.
also I do it without OTHER code changes, I need to know that JUCE is really the issue and not my code…
fortunately, I have many plugins, so thats not too hard to isolate usually, some have been around a long time now…so I trust are stable.

but yeah, its a continual thing… just be aware this is not a ‘one off’

its highly likely, you’ll come back in 6 months, and your plugin will no longer compile on macOS or via clang, and you’ll have to upgrade juce, and go thru this loop again.

I’ll be honest, it’s why Ive considered moving away from juce entirely.
It has been really useful for me, I do like it, but its increasingly feeling bloated / heavy, and also fragile.

but it could be big shift for me,
I could easily re-write the UI side, and it’d probably be not too hard for me to isolate the VST plugin side (used only for macOS testing) and move directly to Steinberg sdk… but I also rely on plugin parameters for the parameter model, and Im not sure how big the shift for that would be…

but yeah, its tempting, real tempting…
if/when I do another refactor, that could well end up on the agenda.