HISE Compatibility with Windows 11 and Cubase 12

[Christoph Hart]

@d-healey have you cleared the error?

[d.healey]

@Christoph-Hart In that snippet I'm not but I did try that inside both the button callback and the error callback.

[d.healey]

Bumpy bump

[Casey Kolb]

@d-healey @Christoph-Hart I haven't managed to get this to work yet even with a simple example. For some reason the error callback isn't being triggered in the compiled plugin or with the simulateErrorEvent function. Am I doing something wrong here?

const var errorHandler = Engine.createErrorHandler();
const var stateLabel = Content.getComponent("critical_Error_State");
const var messageLabel = Content.getComponent("critical_Error_Message");
const var errorModal = Content.getComponent("critical_Error_Modal");

errorModal.showControl(false);

errorHandler.setErrorCallback(function(s, m) {
        Console.print("Error"); // this never prints
	if (s == errorHandler.IllegalBufferSize) {
		showErrorModal("Illegal Buffer Size", "Please change your DAW's buffer size to a multiple of 8 (e.g. 32, 64, 128, 256, 512, 1024, 2048).");
	}
});

inline function showErrorModal(state, message) {
	stateLabel.set("text", state);
	messageLabel.set("text", message);
	errorModal.showControl(true);
}

errorHandler.simulateErrorEvent(errorHandler.IllegalBufferSize);

[d.healey]

@Casey-Kolb Do you have the same problem I had in my snippet?

[Casey Kolb]

@d-healey I'm not using Engine.showErrorMessage so I think it's a slightly different issue. I can't get the setErrorCallback function to trigger with simulateErrorEvent or an actual illegal buffer size in the DAW.

[Casey Kolb]

Bumpy bump!

[Casey Kolb]

@Christoph-Hart Any chance you can take a look at this soon? We’re trying to launch a big update and we really need this error message to work so I don’t get a million support tickets. Thank you

[Christoph Hart]

@Casey-Kolb it‘s fixed now.

[Casey Kolb]

@Christoph-Hart Thank you!!

[d.healey]

@Christoph-Hart Still doesn't seem to be working here, after the first button press the error will never be triggered again.

HiseSnippet 862.3ocsU01aaaCDlxIZXRqsXEq+.D7mjAxLr2x5FPPQciiylQqSMpSK12JXnNGSDJRARpzZTj+y6ev1QJYa4N2hBiVCCCeuxm6g2cbpVw.iQoIAQWtr.HA2Kb1RocwvETtjL9LRvCBmPMVPmTo5zkETiAxHAAG7mNEAQGR7e9mmdJUPkLXiJB4MJNCdAOma2nc5fmyEhyoYvk77Fde7fwLkbnRnJQ7bPXORAkcC8Z3BpysVgjfuaTF2pzyrTKXHAGdpJa4rEp2Iq7+MbC+JA3D5SlgIpR84JQlCwNsjgK3hroqpaCAyxzMrvAUrviBmvy3q0ugM9QugjMQzjOBZsM7NXK30uI750.d6.RAMfzgUP5ggyXZdgciEGd9gvwR7xYNEo8lPoxWRqepU3PE5gz1MmdCbtFEVGQ5i606nD7mNmDGiTuwl.KRdRxH40bIzkoArNFo0J8eQkYBPm14jn3XXQWCX85GREhqvKoz4kRlkqjoB3VPbTRNBQ7lqS7GhiP.XTBnaglKsosQpw1FOw67IKlKE3gkrJAIJ4okVqR12gasRjxT4EJIVAGkbKUTVkS97jzZoHTLBwDS.T8yDBOvLHTQ00UhAuC7pmTAqz1WtfaRvuzDObNJ4Xm+2EEEeGxEqnrqA6vUmdZ6Zb0tiq7qQ2ZB3igcmSZTQWnrvKkodjGeWbxGaZ97cZqNUdheGlcSO5OWfoxx7q.cSdy4H1RsceZ3mtOs4XDqhUZ3nRNVxsur.jepgKRMUh+60iOiZotl6ZcneEf1xcPH3L3VbSQUqdT3Yf4Fqpv6aM+iC+Vu0GTOHTw2DdlKfZxm790qSRfAKWKL3pAF5svX4TMfWdtIDtYhJGyKUitEzh7+m3vYcUVofZ2dAfaqWsAjs2ZpyMYIMb6xlaE+psU3KEhOLbJ2xVraL1ZGXDuS9Vfw5co2Obz74.ytAfGFd9e+sYwI4UpRKWd8DpUywdgvKJymgOmv.7zkRP351wKaWnd4dNYGCLCjYdg+E+TaruSNn1X+UFI4TlV8VV0Llaa8260fXR5enJBewDkS5S7ycXbg851ijiOb7VFyU9+LNpr6X9k8HlecOh438HleaOh4w6QL+9dDye7Yiw8l8yJsp7pwATwzQ9kQAAijTryx2ER9O.NPfXA

[Casey Kolb]

@Christoph-Hart said in HISE Compatibility with Windows 11 and Cubase 12:

@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.

Ok, so this is becoming such an annoying issue and looks so sloppy compared to other VSTs. It's probably our most serious issue and will continue to be even with an error notice.

I think we need a better solution here that allows the plugin to work even when the buffer size is not set to a multiple of 8. I know I can set the HISE_EVENT_RASTER to 1, but shouldn't it be possible to maintain the efficiency of multiple of eight buffer sizes but still allow sound and switch to the less efficient processing when the buffer size is set to a value that's not a multiple of 8?

I'm constantly getting complaints about users not being able to get sound out of their plugin either due to the audio driver settings or buffer size settings, and the users always say CUBE is the only plugin with this issue. Surely there's a better way here right? Ideally it just always works, but the user will experience more CPU usage when using a bad buffer setting.

[Dan Korneff]

@Casey-Kolb same

[Matt_SF]

@Casey-Kolb +1

[Christoph Hart]

It‘s either Eventraster == 1 or the error message. There‘s nothing in between and making this dynamic will not work because this needs to be a compile time constant for efficiency.

EDIT: Fixed that...

[Christoph Hart]

OK, so I thought about it a bit and maybe there's a way how to make it work at least with instrument plugins.

The problem is that the audio buffer that we process in HISE must be a multiple of the EVENT_RASTER (as I said we can't change it inside the engine and make it dynamic as this will cancel most of the performance benefits we get from the system).

Now if there is a buffer size of 441 (aarg!), we must somehow force that buffer into a data block that can be chewed by HISE so we:

1. pad it to the next good buffer size (448) and process the bigger buffer. So now I have 7 left over samples which I need to store somewhere as we only put the first 441 samples back into the original insanely sized buffer. This will only work with instrument plugins where I don't need to process the signal but just create new signals (but to be honest, effect plugins don't benefit this much from the HISE_EVENT_RASTER so it could be just set to 1 there).
2. In the next audio callback which comes in again with annoying 441 samples, I'll put the 7 samples I calculated at the last callback so we only need to calculate 441-7=434 samples. We'll pad that to 440 and again create 6 left over samples.
3. In the next audio callback we put the 6 samples in and get 5 leftovers back (I'll spare you the math but it's the same as above). Effectively the leftover sample amount will be decremented by 1 on each render (if the buffer size would be 442, then it would be decremented by 2).
4. If the leftover sample is 1, then we put a single sample in there, and calculate 440 samples.

This will effectively create a small latency and create some MIDI timing issues, but I'll try to implement it now to see if it works.

[Christoph Hart]

OK and now it gets super embarrasing because I've already implemented THIS EXACT LOGIC already when coping with odd buffer lengths that occur sporadically (like REAPER does when wrapping around loop points or FL Studio does all the time because it's crazy).

So all I had to do was to propagate the padded sample size as max buffer length in the prepare call and let the existing system work out the wrapping (I'm pretty sure that when I implemented this I realized it will not hold up against a permanently wrong buffer size, but that was wrong).

I'll still leave the error message in place for people who try to educate their end users (unless you define HISE_COMPLAIN_ABOUT_ILLEGAL_BUFFER_SIZE=0), but it won't shut the engine down anymore.

[Casey Kolb]

@Christoph-Hart My hero!! :party_popper: