Anybody else seen this?
The plugin window isn’t appearing in the correct location. Happens randomly and usually a resize will fix it. Debian 10.2
Anybody else seen this?
The plugin window isn’t appearing in the correct location. Happens randomly and usually a resize will fix it. Debian 10.2
I’m still having users report this as an issue, anybody else seeing it?
This is still happening for me as well… I don’t know that it was ever actually fixed, but Juce 6 definitely brought it back, and still happening in 6.0.4, related to the changes in XWindow scaling for Linux, it seems.
NOTE: I should add that this seems to only be happening in Waveform on Linux, as far as I can tell. The weird thing is that before the Linux window scaling changes, this was not an issue in any host on Linux.
Yabridge vst2 client has workaround for that. Maybe it can help: Translate mouse coordinates from Wine window · robbert-vdh/yabridge@974951e · GitHub
When loading VST2 plugins in Waveform Version 11.5.17 on Ubuntu the editors appear to be drawn at the correct location. I’ve tried with a few different screen scalings, and with sandboxing enabled and disabled.
If this is still a problem, please provide some instructions to reproduce the issue and I’ll take another look.
Not every VST2 plugin is affected. But MOK’s Waverazor and Filtryg are.
Open it in Waveform or AudioPluginHost you’ll see window border and titlebar behind plugin’s window:
Anyway mouse positioning is correct: click on preset’s name opens presets menu.
Resize the window and all is aligned but mouse position is shifted, I have to drag the cursor right and down to click presets button. Looks like plugin’s window moved inside the frame/borders but widgets bounds - not:
I’ve been looking into this, and I can reproduce the issue with Waverazor LE in the AudioPluginHost, but not in the newest Waveform. I haven’t been able to reproduce the issue in any of the JUCE example VSTs, so debugging has been a bit tricky. I tried running the AudioPluginHost under xtrace and watching the x11 requests/responses. My best guess for what’s happening is that, in cases where the window is drawn at the incorrect location, this happens because sometimes the plugin window is reparented into the host’s window (resetting it’s position) slightly after the correct window position is set by the host. Unfortunately, this reparenting happens on the plugin side, so I think the bug is in Waverazor (and other JUCE VSTs) rather than in the host.
There is a call to XReparentWindow in the VST wrapper. I’m not sure what it’s used for - as far as I can tell, addToDesktop should use the passed window as a parent already, so the additional reparenting call seems redundant.
If you’re able to reproduce the issue there, could you try removing the call to xReparentWindow at juce_VST_Wrapper.cpp:1021 and check whether that solves the issue in Waveform?
Thanks for such thorough test.
If you’re able to reproduce the issue there, could you try removing the call to
xReparentWindowatjuce_VST_Wrapper.cpp:1021and check whether that solves the issue in Waveform?
I haven’t Waveform sources
So I tried with AudioPluginHost and it doesn’t helps, but you give me the direction.
I think we should ping @mok as only their plugins are known for me as affected.
Perhaps recompiling plugins with recent JUCE may help?
Update. Waverazor LE and Filtryg’s titlebars draws correctly in Waveform.
Clicking on controls has problems with preset browser header and settings wheel button, I still have to click it slightly below it’s borders.