Vst2wrapper problem in Cubase/Nuendo only

I’ve got my vst2wrapper-wrapped plugin working now, but in Cubase and Nuendo (64-bit or 32-bit, PC), it is not showing any graphics. The plug-in window is sized correctly, and it responds to mouse movements (like turning the gain up and down), but in Cubase (7,7.5,8,8.5) and Nuendo (6.5) the plugin window is just white. It shows properly in other hosts (Audition,Fruity Loops, Studio One, Digital Performer, SONAR Platinum), just not in the Steinberg products.

This is with VST3 SDK v3.6.6 and VSTGUI 4.3. The VST3 version of this same plug-in works fine in Cubase/Nuendo.

When debugging, my views never get any draw() calls made to them, not even the top level view (a CViewContainer). The controller seems to be initialized properly, as does the sub-controller.

One strange thing, though, is that createView() is called twice. Is that normal? Could that be the problem? One of the calls is from hasEditor(). I see that it first checks the value of gPluginHasEditor is set to either kEditor or kNoEditor. Should vst2wrapper-wrapped controllers be setting that flag in the initialize() function?

Well, setting that gPluginHasEditor flag doesn’t change anything.

It’s as if the are no graphics present, even though I can see that my views are all created (and have valid bitmaps and sizes set), and they respond properly to mouse gestures. They simply never get any draw commands!

UPDATE: the only mouse gesture they respond to appears to be the wheel. But that doesn’t go through WindowProc()… it comes via vendorSpecific()! So for some reason it looks like my mouse and draw commands are not going through the windows message system, as if the frame was not created. I CAN get it to stop in WindowProc() when opening and closing the window, and everything appears to be as expected then, but obviously there’s a step getting skipped or unexpected result being returned somewhere.

Any ideas why that might occur when using the vst2wrapper, and apparently only for Cubase/Nuendo?

Hi Howard

First, for VST2, yes it is normal for createView( ) to get called twice; the first time, as you saw, was when the host checked to see if you have an editor - interestingly, it does this by trying to create your view. If you put a breakpoint there you can track back to the hasEditor( ) function and see if it eventually returns TRUE that you do have a GUI. Secondly, also yes, setting that hasEditor flag does nothing for me either - true or not, the VST2 client still does that “fake instantiation” GUI check.

I have only had one issue with the VST2 wrapper + GUI:

MacOS Only: VST2 clients provide a HIView pointer, not a NSView pointer, for the GUI Window. If you have written a custom GUI that has its own open( ) function, then you need to make sure you have code that supports HIView – this fooled me on a project last year; the GUI was blank on my Mac VST2, which happened to be running in Cubase. On the PC side, I was testing the VST2 with Reaper and had no problems, and so I mistakenly thought it was a Cubase vs. Reaper problem, when in reality it was Mac vs. Win. And of course, everything was just fine on the VST3 version, both Mac and Win showed the GUI correctly.

Does your GUI window support resizing? If so, different clients appear to handle this differently. You might want to check the beforeSizeChange( ) method to see if it is ultimately returning FALSE, which will make the client give a blank/incorrect GUI. That happened to me on a few projects. but I would think you’d have the same issues on VST3 as well.

As an acid test, you can always compile the NoteExpressionSynth with the vst2wrapper (being careful about those #include paths…) and run/debug that code to compare against. It uses VSTGUI4.3 and the XML File.

BTW, I use both the XML File + UIDescription paradigm as well as pure Custom GUIs, deriving my base class from VST3Editor, and I’ve had success both ways. Also using SDK3.6.6 + VSTGUI4.3

Hope you get it fixed sooner than later -

  • Will

Thanks, Will. Our GUI is not resizable (its min and max are the same). And this only happens with Cubase/Nuendo and only with the VST2 version using the wrapper. (We don’t make a VST2 version for the Mac currently, so I don’t know if it would happen there or not.)

Debugging hasn’t shown me anything yet. Everything seems to initialize correctly.

Ah, you have set me on the right track, though, Will. I have found that regardless of whether requestResize() (and thus beforeSizeChange()) return kResultTrue or kResultFalse, it will give me a blank screen if Vst2EditorWrapper::resizeView() returns false. If that function returns true, then my GUI shows up normally!

It looks like resizeView() calls the effect’s sizeWindow() function, which is returning false, and that is causing resizeView() to return false, which ends up causing the GUI to not show up in Cubase/Nuendo. (No idea why that should be the result, though.)

I can’t trace the problem further than that, though, because AudioEffectX::sizeWindow() calls audioMaster() with audioMasterSizeWindow, which isn’t in the plug-in code. That returns false in Cubase and Nuendo, and that cascades back to the problem of the GUI not showing.

Anyone know how to resolve this Cubase/Nuendo problem? I could simply return true from resizeView() no matter what, but that’s an SDK change I’d rather not make if I wasn’t sure it was the only reasonable solution.

Ok, I see a fix, although I’m not sure if it’s the correct thing to do or not.

In AudioEffectX::sizeWindow(), before calling audioMaster() with audioMasterSizeWindow, I can check if the host supports that by calling audioMaster() with audioMasterCanDo and the ptr value canDoSizeWindow. When that returns 0 (as it does in Cubase and Nuendo), I can return true from sizeWindow(). Otherwise, I can go ahead and call audioMaster() with audioMasterSizeWindow. Doing this makes my GUI appear properly in Cubase and Nuendo.

But like I said, I don’t know if this is the right thing to do or not. Will it break plug-ins that resize their windows dynamically? Or cause other problems? So far, it’s the only solution I see, though.

That, or modifying Vst2Wrapper::resizeView() to ignore the return value of AudioEffectX:sizeWindow().