HISE Compatibility with Windows 11 and Cubase 12

[d.healey]

@dustbro I think you need to compile your project with that flag, not HISE itself.

[Dan Korneff]

@d-healey

[Dan Korneff]

@Christoph-Hart raster size of 1 works

[Casey Kolb]

@Christoph-Hart Will that extra definition affect anything else? Do we just need to set that in our projects?

[Christoph Hart]

@Casey-Kolb Yes of course, this vastly increases CPU usage because it will render all modulators at full audio rate.

I just wanted to confirm that it's actually this flag that's causing the problem. Setting it to 1 is not the fix.

[Casey Kolb]

@Christoph-Hart Noted!

[Dan Korneff]

@Christoph-Hart Do you need any other info to help debug?

[Casey Kolb]

Bumping this issue again. It's rather pressing and I'm getting more and more support tickets about this. Our users can't use the plugin at all in the newer version of Cubase.

@Christoph-Hart Any idea when we'll have a fix for this?

[Christoph Hart]

@Casey-Kolb They just need to set a buffer size that is a multiple of 8. I have no idea why this isn't enforced by audio drivers.

[Casey Kolb]

@Christoph-Hart Why do other non-HISE VST plugins still work regardless of this? Is there a way we can safeguard against that in HISE?

[Christoph Hart]

@Casey-Kolb Yes, actually it shows an error message that the buffer size is wrong but if you deactivate the overlay it won't show up.

[Casey Kolb]

@Christoph-Hart Got it. Is there a reason this is a HISE-specific thing? Other plugins don't seem to have issues with the different buffer sizes (correct me if I'm wrong). Most of these support tickets from our users say CUBE is the only plugin that doesn't work with their settings, which is a pretty bad look.

[Christoph Hart]

@Casey-Kolb Yes this is a deliberately optimization in HISE that ensures that the CPU usage is as low as possible. By enforcing this all the modulators can run at 8x times lower than audio rate so it saves huge amounts of CPU. Try setting the HISE_EVENT_RASTER to 1 and compare the CPU usage.

There is absolutely no reason not to use a buffer size other that's not a multiple of eight except for ignorance on the end user's part (or lack of better knowledge).

It deals with varying buffer sizes pretty well (REAPER for example splits up buffers at the loop point), but if the buffer size isn't dividable by eight, you will get periodic crackling, so I shut down the processing and show the error message in the overlay.

I might add a way of catching and displaying these messages when the overlay isn't disabled, but apart from that there's nothing to be done - except for setting HISE_EVENT_RASTER to 1 and explaining every user why the CPU has increased in your last update.

[Casey Kolb]

@Christoph-Hart Noted.

[Casey Kolb]

@Christoph-Hart Will Settings.getCurrentBufferSize() work as a check when the user loads the plugin? I'm thinking we might just add our own overlay so we can keep the main HISE overlay off.

[Christoph Hart]

@Casey-Kolb I think a better way is to add a custom error handler as this might also catch other critical errors (eg. samples not found or the copy protection being invalid).

You can also use this with:

HISE | Docs

(docs.hise.audio)

[Casey Kolb]

@Christoph-Hart Our CUBE OpenGL component overlays everything regardless of order, so we have to go custom for all modals in order to hide the OpenGL first

Just confirming that Settings.getCurrentBufferSize() will return the DAW's buffer size and not just the Standalone buffer size?

[Christoph Hart]

@Casey-Kolb I would add something like

Engine.setErrorCallback(function(message, isCritical)
{
    if(message.length == 0)
    {
        myPanel.set("visible", false);
        return;
    }

    myPanel.set("visible", true);
    myPanel.data.text = message;
    myPanel.repaint();
});

then you can show this however you like - no need to overlay everything.

[d.healey]

@Christoph-Hart That looks like a good solution!

[d.healey]

@Christoph-Hart

Engine.setErrorCallback(function(message, isCritical)

This isn't in the API yet is it?