Handles VST sub-windows and is used by vestigeInstrument. A new sub-class of VstPlugin, VstInstrumentPlugin, now VstPlugin into vestige.cpp, which is the only place where sub-window VSTsĪre actually used. All sub-window related code was moved out of Windows, which aren't needed with VST effects, but were still created, This commit refactors some code in order to avoid creating unnecessary sub. In some situations, thisĬaused createUI to be called twice, leaving over multiple empty widgets. Inconsistencies between the way VST UIs were created when loading a projectĪnd when adding an effect in an existing project. Widgets and sub-windows would be left floating around. Ignore the top row for the case when the plugin is not visible when savedįixes bugs where during project loading (observed with VST effects), empty When the plugin is hidden on project load, the first call to createUI never happens ( hideUI is called instead of showUI), and in that case the empty window doesn't appear (since the plugin isn't moved to a new container), but there is still a box (since the container is still reparented to the control dialog).ĭiagram of case when plugin is saved as visible: The empty window is the vstSubWin from the first call to createUI that still contains a plugin container the plugin is moved to a new container on the second call to createUI and the new container is put in the VstEffectControlDialog, leaving the second vstSubWin as the box. I've tried it with a fresh plugin (not loaded from a project) and the window is still added, it's just 0x0 so it's never seen. when it is a VSTi loaded into VeSTige, but not when the plugin is inside another window, i.e. Presumably vstSubWin is supposed to be used when the plugin is meant to be a direct MDI child, i.e. This leaves a childless vstSubWin, which is the strange box. VstPlugin::m_pluginWidget is then set to the container window, and VstPlugin::m_pluginSubWindow to the vstSubWin wrapper.īut in VstEffectControlDialog::VstEffectControlDialog, m_pluginWidget is set to m_plugin->pluginWidget( false ), which returns VstPlugin::m_pluginWidget, which is then added into the VstEffectControlDialog. The effect's container window is wrapped in a vstSubWin in VstPlugin::createUI. I think I've found where the "strange box" mentioned in the bug report comes from: When the plugin is saved visible, createUI is called twice upon load, which leaves an empty plugin container as the VST's UI is moved into the second one created. Investigations by from Discord (I hope you don't mind me copying them here): Although Qt is showing the detached GUI of the empty window, just not the way it should, I guess: "Works" with both plugin embedding methods: Win32 API and Qt. In this screenshot I resized it over the actual GUI.Īnd here is another image, very clearly showing that the black square of the NaN-Detector isn't drawn into the background.Īlso, the affected projects I tested it in had in common, that there was a (almost) empty window of the size of the effect GUI leftover after loading the project (as seen in the video). I think this might be related to the rendering of the VST GUI. However, the recording software didn't record the cursor correctly, so imagine a resize arrow whenever I'm resizing the box (or am having trouble picking up the effect window). I think this is best explained by a short videoīasically, when I load up a project with an effect plugin and open the controls window of an effect on the master channel (different channels not yet tested), there is a strange box with no (?) content, which keeps whatever was printed last in it. I don't really know how to summarize this bug briefly. Please change the title to something more descriptive.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |