Near instant crash with today's commit

[DanH]

Just opened my project with commit from earlier today on OSX. I exported an au which crashes DAWs on loading, and if I try and scroll around the screen in HISE it also crashes. Anyone else?

[DanH]

@DanH just tried the latest as well with the same result....

[DanH]

@DanH crash report here

[DanH]

@DanH Seems to be linked to the Goniometer - if I set it to non-visible I can scroll around the UI in HISE, but when I make it visible again -> instant crash @Christoph-Hart

[d.healey]

@DanH Make a test project with just that module and see if you get the same result.

[DanH]

@d-healey So a Goniometer on it's own is ok but if you mix it up with the spectral analyser or oscilloscope and have multiple windows using the same analyser module it gets buggy and crashes. I think something might have changed here recently with fft?

[DanH]

@DanH it's seemingly stable if the Goniometer has it's own analyser to itself. There's some rather glitchy ui stuff happening however, lots of flickering and the grid has superimposed itself into the floating tile in a crisp white...

[DanH]

@DanH ok so on top of this the Spectral Analyser has also changed how it displays the signal, seems completely different to before.

@Christoph-Hart has there been a big development of the analyser? Perhaps a Projucer 6.1.4 thing?

[Christoph Hart]

So a Goniometer on it's own is ok but if you mix it up with the spectral analyser or oscilloscope and have multiple windows using the same analyser module it gets buggy and crashes.

Yeah, that makes sense, I have rewritten the system in order to couple the analysers with the display mode more tightly (so you can change additional properties like FFT Window type etc).

I would simply suggest to use one analyser per type (I'll add some error reporting some time that prevents multiple analyser windows reading from the same module).

[DanH]

@Christoph-Hart Ok, will that increase overhead out of interest? And what to do about the spectral analyser - it doesn't seem very useful in it's current state. Or do I need to change a new setting?

[ustk]

@Christoph-Hart said in Near instant crash with today's commit:

Yeah, that makes sense, I have rewritten the system in order to couple the analysers with the display mode more tightly (so you can change additional properties like FFT Window type etc).

But unfortunately this doesn't work in the end. The display buffer read is unusable, and createPath kind of works but only for small buffer sizes up to 4096. With higher values it becomes glitchy as hell...

[DanH]

@ustk where are the settings?

[ustk]

@DanH https://forum.hise.audio/topic/5791/spectrum-ballistic-display-buffer/2

[DanH]

@ustk oh ok, so the modifications are for scriptnode but they also affect the Analyser Module FX too? And they're broken anyway?

[ustk]

@DanH said in Near instant crash with today's commit:

@ustk oh ok, so the modifications are for scriptnode but they also affect the Analyser Module FX too?

This I don't know...

And they're broken anyway?

Yep the display buffer methods don't work (you can get something but it's very glitchy...)

[DanH]

@ustk thanks. @Christoph-Hart so is that it for the old analyser then? Is this pretty much a breaking change for old projects? Happy to use a second analyser but the spectral analyser is all blocky and at a super low level. Trying to roll back to an earlier commit but there’s the logic version issue as well

[Christoph Hart]

@DanH Yes, I'm currently busy with other stuff, but I'll restore the analyser soon.

If you want you can work on a good set of default values that mimic the old behavior: Just add a analyse.fft node, click on Edit Properties (like the screenshot in the other post shows) and when you come up with a magic JSON that looks super nice, post it here and I'll put it as default.