Hosted plugin VST3 editor repaint issue

I’m working on a plugin that hosts other plugins.

We have the (possibly ambitious) feature of allowing the hosted plugin’s editor to be shown either within the parent plugin’s window, or as a separate window. When shown within the parent’s window it is centred on top of an overlay.

When showing within the parent editor window, on Windows, when the hosted plugin is a VST3, I’m seeing repaint issues. I can still interact with the plugin via the mouse, but to see the effects of the interaction (e.g. sliders moved or buttons on/off) I need to resize or move it. I’ve been looking for a way to force the plugin to repaint itself. The closest I’ve got so far is calling setVisible with false then true on a Timer…

I’ve not seen this issue with VST2 or AU plugins.

Anyone else ventured into this perilous territory before?

Is there anything special about the VST3 plugins you’re testing? Are they JUCE plugins? Have you tried them in the AudioPluginHost, and do they work correctly there?

Have you tried the wrapper plugin in multiple hosts? If so, do you see the same problem in all hosts?

Are you using a display scale other than 100%? Do you get different results if you set the display scale to 100% and relaunch everything?

As it is, it sounds like there could be some issue in JUCE’s VST3 view hosting code, but I’m not sure where that could be. I’ve got a little plugin-hosting-plugin that I use for testing and that seems to repaint hosted VST3s correctly when building from develop (testedwith Massive X and some JUCE plugins), so perhaps the issue is caused by something else in your particular plugin. Does the plugin create multiple windows or anything like that? Is the ‘overlay’ a subcomponent of the wrapper’s editor, or a whole new HWND?

So far I’ve tested with TAL U-NO-LX (which is JUCE AFAIK), that displayed the problems described, and Surge, which does not show it’s editor at all unless I manage to change a preset and then it paints it’s UI.

If I choose to show the hosted plugin in it’s own Window, that works fine. The issue seems to appear the same in standalone or as a VST2/3 in the hosts I’ve tested (Ableton and FL Studio).

I think the issue is likely to be with the way we’re showing the plugin within a subcomponent of the wrapper’s editor.

@reuk just to let you know that this problem was resolved. I’m not 100% sure what was causing the issue, but it was definitely due to something odd happening on our side related to tracking the size of the hosted plugin editor. Some other issues related to scaling have arisen but I think we can close this thread now.

1 Like