VST SDK 3.6.7, latest JUCE tip: VST3 crashes Sonar


Quick question: when I update JUCE to the latest master tip, and use the latest VST SDK (v3.6.7), VST3 plugins in Sonar crash; this does not happen when reverting to to VST SDK v3.6.6 and JUCE prior to the Steinberg VST sdk update.

The issue seems to be related to program changes. Specifically, the function EditController::getParameterInfo (int32 paramIndex, ParameterInfo& info)
(vsteditcontroller.cpp, line 107) gets called with the parameter ID (1886548852) instead of the parameter index (19 in my case) and hence the function parameters.getParameterByIndex(paramIndex) returns an invalid address.

Any ideas? Did someone encounter this as well in Sonar (Windows, 64 bit)?


Ok to follow up on this one:

  • Other hosts like Reaper don’t have this issue; they call getParameterInfo with the correct argument (parameter index) for both VST3 SDK v366 and v367

  • The reason why v367 gives a crash and v366 does not has to do with v367 throwing an error if an array index is out of bounds and v366 does not.

  • This therefore seems a Sonar bug; it simply seems to mix up the parameter index and the parameter Id specifically for program change parameters.

Not sure if we can modify JUCE in a way that this issue is prevented; Sonar calls the function in vsteditcontroller.cpp directly and not from within any JUCE function…? I’ll see if I can get this under the attention of Sonar devs.

Yeah, doesn’t sound like something we could or should fix, but let us know if there’s anything non-hacky we could change that would help.

If I understand correctly this issue also happens when using VST SDK 3.6.7 without using JUCE.
Therefore a non-hacky thing that JUCE could do to work around this is to support using older VST SDKs.

ah, glad it’s not just me… i thought i was going to have to deal with more Sonar strangeness…

I just got an email about a new release of Sonar… 2017.03


Sonar has acknowledged the issue and they are looking into it.

On the JUCE front: not sure if there would be an easy, non-hacky solution to increase robustness against this bug. I guess subclassing the relevant VST3 class and overriding the function that creates the problem to add a check for an index that is out of bound could potentiall be done (not sure if that would work?), but this won’t resolve the actual underlying issue.

Sonar 2017.04 should contain the fix for this issue.

As we’re getting closer to update our build system with latest SDKs.

What’s the status on that? my main concern is older SONAR user that didn’t upgrade to latest and greatest. would using a newer SDK break anything for them?

1 Like

VST3 3.6.8 has just been released, and we’ll be updating JUCE to use that shortly.

Hi Tom, does this mean that from the next version of Juce we’ll be forced to use VST 3.6.8?

No - the next version of JUCE will be compatible with both 3.6.7 and 3.6.8.

FWIW, regarding SONAR specifically, Cakewalk has recently ceased all of its development due to a decision of Gibson, which currently owns it:


Yeah, I saw that (it was after my post here). though this just makes me wonder more for those users how’d use our products on older Cakewalk products. will the use of 3.6.7 or greater with older Cakewalk would break. (since I got no answer so far I promise to update once we’ll update or current build workflow to latest SDKs and VS2017).

Great, thanks.

Just an update on this specifically, Sonar is now known as Cakewalk by BandLab and is complete free. See:

I’m getting reports of crashes with vst3 plugins made with Juce and Calkwalk by Bandlab. Does anyone know more about vst3 sdk compatibility and Cakewalk? Is 3.6.7 the only problematic version or do all versions after 3.6.6 lead to crashes? Has this issue been resolved?