[Bug 58552] New: Yabridge plugins GUI is not located on the exact location of the GUI element (WINE 10.12)
http://bugs.winehq.org/show_bug.cgi?id=58552 Bug ID: 58552 Summary: Yabridge plugins GUI is not located on the exact location of the GUI element (WINE 10.12) Product: Wine Version: 10.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: akidevera0(a)gmail.com Distribution: --- hi, i use vanilla OS debian unstable. i have a problem on wine version 10, Where the GUI is not located in the exact gui element. i keep clicking on the empty places, it makes a sound. i don't know why its like that, but i hope you can fix it. I'm suffering installing wine 9.0 since the older packages is not available in the newer versions of Vanilla/Debian. I hope this can be fixed sooner. -Yuji Chen, Vanilla OS 2 (Debian Sid) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #1 from Austin English <austinenglish(a)gmail.com> --- Hi Yuji, Does this application have a free demo/download available that can reproduce the issue? Can you please attach a screenshot showing the problem (and a screenshot from windows showing the correct behavior, if possible). Lastly, please attach the terminal output. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 Stian Low <wineryyyyy(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy(a)gmail.com --- Comment #2 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Austin English from comment #1)
Hi Yuji,
Does this application have a free demo/download available that can reproduce the issue? Can you please attach a screenshot showing the problem (and a screenshot from windows showing the correct behavior, if possible). Lastly, please attach the terminal output.
This seems to be related to a known yabridge wine issue: https://github.com/robbert-vdh/yabridge/issues/382 Sample VSTs (extracted as ~/Downloads/VST\ Plugins): https://archive.org/download/trance-gate-2-x-32/VST%20Plugins.zip To reproduce (with a fresh and so clean ~/.wine): 1. yabridge prep (vst handler) 1. Extract as ~/.local/share/yabridge: https://github.com/robbert-vdh/yabridge/releases/download/5.1.1/yabridge-5.1... 2. ~/.local/share/yabridge/yabridgectl add ~/Downloads/VST\ Plugins/VST\ Plugins/ 3. /home/any/.local/share/yabridge/yabridgectl sync 2. carla prep (audio/music studio that uses yabridge to handle vst plugins) 1. Extract as ~/Downloads/Carla_2.2.0-linux64: https://github.com/falkTX/Carla/releases/download/v2.2.0/Carla_2.2.0-linux64... 2. ~/Downloads/Carla_2.2.0-linux64/Carla Step 2.2 launches Carla. 3. Add yabridge to carla 1. Click "Add Plugin" button to open "Add New" popup window 2. Click "Refresh" button in "Add new" popup window to open "Refresh" popup window 3. Click "Scan" button in "Refresh" popup window to scan/import ~/.vst/yabridge 4. Click "Close" button in "Refresh" popup window to return to "Add New" popup window 5. Uncheck all except "VST2" checkboxes in "Format" panel at top right side of "Add New" popup window 6. Check mark VST lists in the center panel including the VST named "Future" 7. Select the VST named "Future" in the center panel and click "Add Plugin" Step 3.7 adds the VST via yabridge via wine represented in Carla as a rack on the default Rack tab. 4. Open VST GUI to reproduce offset issue: 1. Click the button represented by a gear icon for VST Rack added to the Rack tab (gear button located between the buttons with power and wrench-tool icons at the top left of the VST Rack) 2. Move the mouse over the large top right most knob in the VST window and try to click and drag to turn the knob Step 4.2 failed due to the GUI offset issue because the large topright most knob is outside the offset space. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #3 from Stian Low <wineryyyyy(a)gmail.com> --- Partial workaround for Wine 10.12 on Debian 12: 1. Run `wine winecfg` to open wine configuration 2. Click "Graphics Tab" 3. Click "Emulate a virtual desktop" 4. Click OK 5. Retest yabridge and confirm GUI offset resolved This workaround fixes the GUI offset. VST still appear in their own separate windows and the mouse aligns with the buttons and properly. However the combobox controls although clickable, their options popup appears in the Wine virtual window rather than in the dedicated VST window. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #4 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 79086 --> http://bugs.winehq.org/attachment.cgi?id=79086 Screenshot partial workaround with winecfg virtual desktop Attached is a snapshot of 2 instances of the "Future" VST described in the reproduce steps loaded into Carla with winecfg virtual desktop enabled. The virtual desktop window at the left side was brought from the background to the forefront but doesn't showcase the combobox options described by the workaround because for some reason Debian 12 snapshot tool won't trigger via the PrintScreen button while combobox is active with options shown. As soon as the combobox is unfocused and options are hidden the snapshot tool is triggered by the Printscreen button again. Oddities. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #5 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 79087 --> http://bugs.winehq.org/attachment.cgi?id=79087 Screenshot of VST working for Wine 8.0 (Debian 12) Attached is a screenshot showcasing the expected VST functionality working for wine-8.0 (Debian 8.0~repack-4). The combobox dropdown options appear with the button which is aligned and clickable via the mouse. This 8.0 test reinforces the yabridge bug that reports issues around Wine 9.22: https://github.com/robbert-vdh/yabridge/issues/382 Regarding the prevoius Wine 10.12 tests, the GUI offset issue was reproduced for both Wayand and X11. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #6 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Stian Low from comment #5)
The combobox dropdown options appear with the button which is aligned and clickable via the mouse.
For clarity, the 8.0 test was run with a fresh ~/.wine and without the winecfg virtual desktop enabled mentioned as a partial workaround for 10.12. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Yabridge plugins GUI is not |Yabridge plugins GUI is not |located on the exact |located on the exact |location of the GUI element |location of the GUI element |(WINE 10.12) | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #7 from Stian Low <wineryyyyy(a)gmail.com> --- Related: https://bugs.winehq.org/show_bug.cgi?id=57754 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #8 from Stian Low <wineryyyyy(a)gmail.com> --- Also related: https://bugs.winehq.org/show_bug.cgi?id=58506 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #9 from Stian Low <wineryyyyy(a)gmail.com> --- See yabridge dev Robbert van der Helm responses for further details regarding this issue: https://gitlab.winehq.org/wine/wine/-/merge_requests/6569 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #10 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 79097 --> http://bugs.winehq.org/attachment.cgi?id=79097 Patch to commit 8fa114fae34 (wine-10.11) Via the glory of https://gitlab.winehq.org/wine/wine/-/wikis/Regression-Testing#running-the-b...: Bisect Rest (2) d8b5a3ae129 * @ winex11: Update the window client config on window state changes. 03738c3f22f * winex11: Wait for pending ConfigureNotify before updating the client state. Commit d8b5a3ae129 to dlls/winex11.drv/window.c involving "data->wm_state_serial" introduced the bug. The patch simply comments a line added for wm_state_serial which fixs the GUI offset issues described in the reproduce steps. This may not be a proper fix based on discussions at: https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#05752921556c31c592... This patch is a temp workaround for now until further review and updates focus to the underlying issue involving wm_state_serial at dlls/winex11.drv/window.c. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #11 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 79098 --> http://bugs.winehq.org/attachment.cgi?id=79098 Improved patch to commit 8fa114fae34 (wine-10.11) This patch overrides the previous patch with improvements. The previous patch still had GUI offset issues once a VST window was moved. Also, when multiple VST windows were open only the last one that was open was properly aligned with the mouse. This patch keeps the mouse aligned even if the VST window is moved and supports multiple VST windows which can also be moved. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #12 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 79099 --> http://bugs.winehq.org/attachment.cgi?id=79099 Screenshot showcasing latest patch This screenshot showcases the latest patch improvements. All VST window controls were aligned with the mouse and all windows could be moved anywhere and the controls remained aligned to the mouse. It doesn't showcase the dropdown menu open because for some reason the Debian snapshot tool is disabed again when its open. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 Patrick <patrick+winehq.org(a)laimbock.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |patrick+winehq.org(a)laimbock | |.com --- Comment #13 from Patrick <patrick+winehq.org(a)laimbock.com> --- Thank you for your efforts to bisect the issue. I just tested your latest patch (and MR 8669 from https://gitlab.winehq.org/wine/wine/-/merge_requests/8669) in a wine-tkg 10.12 build and Bitwig 5.3.12. It works in Bitwig when the VST window initially appears. But once you hide the VST window in Bitwig and make it appear again then it stops working. I'll test again with just your latest patch (so without MR 8669). In case you use Fedora 42 x86_64 then you can find my wine build here: https://copr.fedorainfracloud.org/coprs/patrickl/wine-tkg-dev/ -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #14 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Patrick from comment #13)
Thank you for your efforts to bisect the issue. I just tested your latest patch (and MR 8669 from https://gitlab.winehq.org/wine/wine/-/merge_requests/8669) in a wine-tkg 10.12 build and Bitwig 5.3.12. It works in Bitwig when the VST window initially appears. But once you hide the VST window in Bitwig and make it appear again then it stops working. I'll test again with just your latest patch (so without MR 8669).
In case you use Fedora 42 x86_64 then you can find my wine build here: https://copr.fedorainfracloud.org/coprs/patrickl/wine-tkg-dev/
Thanks for testing and the links. I'm Debian 12 but Fedora ref still appreciated. I retested opening and closing VST windows against Carla and it worked fine with the latest patch against latest commit 8fa114fae34 pulled today. I'll try to reproduce on Bitwig (assuming the Linux version and not Windows). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #15 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 79103 --> http://bugs.winehq.org/attachment.cgi?id=79103 Snapshot of Bitwig error when trying to load yabridge *.so (In reply to Stian Low from comment #14)
(In reply to Patrick from comment #13) I'll try to reproduce on Bitwig (assuming the Linux version and not Windows).
I will need help to reproduce Bitwig issues reported. Windows Bigwig allow VST dlls to be loaded directly but VST dlls don't appear for Linux Bitwig. The ~/.vst/yabridge *.so files from the VST dlls appear but upon loading one produces the error shown in the top right corner of the window. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #16 from Patrick <patrick+winehq.org(a)laimbock.com> --- I built wine WoW64 HEAD (no staging) from commit https://gitlab.winehq.org/wine/wine/-/commit/91d3874b6528cb71b346c1d114914bc... + your latest patch + https://gitlab.winehq.org/wine/wine/-/merge_requests/8669 and I tried Blamsoft VK-1 Viking synth and Voxengo SPAN (both free) in Bitwig (on Linux). Blamsoft VK-1 Viking -------------------- When it first appears: The mouse offset is present When I move the VK-1 window: I can use the knobs Selecting presets works When I close the VK-1 window in Bitwig and make it appear again: The mouse offset is back When I move the VK-1 window to the topleft: I can use the knobs When I move the VK-1 window: I can still use the knobs Voxengo Span ------------ When it first appears: I can use the knobs Sometimes the mouse pointer was not visible in the Span window and I had to move the Span window so the cursor appears. Then I could use the knobs When I move the Span window: I can still use the knobs When I close the Span window in Bitwig and make it appear again: The mouse offset is back When I move the Span window to the topleft: I can use the knobs When I move the Span window: I can still use the knobs -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #17 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 79105 --> http://bugs.winehq.org/attachment.cgi?id=79105 Screenshot of VK-1 Viking Synth and Voxengo SPAN in Carla via yabridge Thanks for feedback. Attached is a screenshot of 2 instances each of "Blamsoft VK-1 Viking" and "Voxengo Span" VSTs running in Carla via yabridge. Regarding the GUI offset issue, the mouse aligns with all controls and still works when moving windows around arbitrarily. The only misbehavior (minor and may be outside the scope of GUI offset fixes) is child windows always appear on top in the order in which they were opened. This is showcased by the screenshot of "Voxengo Span" Routing child windows open for both instances. Otherwise everything seems to work as expected. I still need guidance on how to load the VSTs for Linux Bitwig. Linux Bitwig still throws the error shown in the top right corner of the previous screenshot when loading yabridge *.so files for these latest 2 VSTs. Does Linux Bitwig load VSTs differently than yabrige *.so files? Still seeking Bitwig docs that describe how to load VSTs for Linux. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #18 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Patrick from comment #16)
When I close the Span window in Bitwig and make it appear again: The mouse offset is back
Also, for clarity, all VST windows opened without the GUI offset for Carla/yabridge and could be closed and reopened without the issues described for Linux Bitwig. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 solin arrin <solin-arrin(a)protonmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |solin-arrin(a)protonmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 solin arrin <solin-arrin(a)protonmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|solin-arrin(a)protonmail.com | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 solin arrin <solin-arrin(a)protonmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |solin-arrin(a)protonmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #19 from Patrick <patrick+winehq.org(a)laimbock.com> --- (In reply to Stian Low from comment #17)
Created attachment 79105 [details] Screenshot of VK-1 Viking Synth and Voxengo SPAN in Carla via yabridge
Thanks for feedback.
Attached is a screenshot of 2 instances each of "Blamsoft VK-1 Viking" and "Voxengo Span" VSTs running in Carla via yabridge.
Regarding the GUI offset issue, the mouse aligns with all controls and still works when moving windows around arbitrarily.
I have the same test results with wine/wine-staging 10.13 with your latest patch and MR8669.
The only misbehavior (minor and may be outside the scope of GUI offset fixes) is child windows always appear on top in the order in which they were opened. This is showcased by the screenshot of "Voxengo Span" Routing child windows open for both instances.
I did not test multiple instances. Thanks that's good to know.
Otherwise everything seems to work as expected.
That's great!
I still need guidance on how to load the VSTs for Linux Bitwig. Linux Bitwig still throws the error shown in the top right corner of the previous screenshot when loading yabridge *.so files for these latest 2 VSTs.
Does Linux Bitwig load VSTs differently than yabrige *.so files? Still seeking Bitwig docs that describe how to load VSTs for Linux.
AFAIK there are no docs. The yabridge discord https://discord.gg/pyNeweqadf is the go-to-place if you have problems. Feel free to ping me (my nick is patrick_copr). In Bitwig you need to configure where it can find the VSTs. Go to Settings (on top) -> Locations (left sidebar) -> Plug-in locations -> + Add location. Assuming that your VST2 plugins are in ~/.vst and VST3 plugins are in ~/.vst3, those locations need to be added to Bitwig. For me it shows: /home/test/.vst /home/test/.vst3 In Bitwig if you get errors (like you reported) then go to Settings (on top) -> Plug-ins (left bar) -> Show plug-in errors (middle bottom) and then read the error messages. Please note that 32bit Win plugins are not supported with wine WoW64 builds as yabridge does not support that. See https://github.com/robbert-vdh/yabridge/commit/acbb8063f31dc3f40a3614b231361... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #20 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 79146 --> http://bugs.winehq.org/attachment.cgi?id=79146 Screenshot of Bitwig reproducing Carla screenshot (In reply to Patrick from comment #19) The yabridge discord https://discord.gg/pyNeweqadf
is the go-to-place if you have problems In Bitwig if you get errors (like you reported) then go to Settings (on top) -> Plug-ins (left bar) -> Show plug-in errors (middle bottom) and then read the error messages.
Thanks for much appreciated Bitwig guidance and more links. Bitwig "Show plugin-in errors" button revealed the most relevant and otherwise hidden message: Could not find libyabridge-vst2.so Originally flatpak was installed instead of .deb: https://www.bitwig.com/download/ But flatpak did not find ~/.local/share/yabridge/libyabridge-vst2.so despite adding it to LD_LIBRARY_PATH Installing .deb instead of flatpak resolved the error. Attached is a Bitwig screenshot reproducing the latest Carla test with 2 instances each of "Blamsoft VK-1 Viking" and "Voxengo Span" VSTs. Bitwig behavior is practically identical to Carla. MR8669 has not be included for any of these tests. Only the simple patch commenting 1 line. This latest test is running on Debian 13 which was upgraded to over the weekend. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 Alfonso <winehq(a)alias.alfelfriki.tech> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq(a)alias.alfelfriki.tec | |h -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #21 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 79153 --> http://bugs.winehq.org/attachment.cgi?id=79153 Screenshot of REAPER with 3 instances of Blamsoft VK-1 Viking VST Attached is a screenshot of Reaper running against my latest patch against 75b9e1722d1 Release 10.13 commit on Debian 13. The behavior is practically identical to that of Carla and Bitwig. A minor bug was found which causes the knobs and hover popup labels to flicker to an offset position and back. This is showcased in the screenshot by the "Osc 2 Frequency: 3.8 semitones" label. The flickering doesn't start until the mouse has settled motionless for 1 to 2 seconds. I'm reviewing all merge requests leading to this bug report to stage a solution that may be submitted as a merge request. The virtual desktop workaround seemed the simplest way to fix if not for the dropdown menus opening inside the virtual desktop window instead of the VST window. The popup labels for knob controls also appear in the virtual window but don't flicker but instead appear and disappear quickly rather than remaining displayed while hovered. File explorers for VST save/open buttons are also open in the virtual desktop window. Therefore it seems for virtual desktop mode the effort should be to make the VST windows all appear within the virtual desktop rather than popups appear outside it and aligned with the improperly displayed VST windows. Whatever virtual desktop mode fixes to make the knobs and controls work for the independent VST windows is a hint what needs to happen when virtual desktop mode is turned off. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #22 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Stian Low from comment #21)
A minor bug was found which causes the knobs and hover popup labels to flicker to an offset position and back. This is showcased in the screenshot by the "Osc 2 Frequency: 3.8 semitones" label.
Typo correction: only the hover popup labels flicker and not the knobs themselves which otherwise continue to work as expected. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #23 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 79156 --> http://bugs.winehq.org/attachment.cgi?id=79156 Screenshot of LMMS with 3 instances of Vestige Blamsoft VK-1 Viking VST Attached is a screenshot of LMMS with 3 Vestige (VST plugin handler) instances of "Blamsoft VK-1 Viking" tested against my latest patch for 75b9e1722d1 Release 10.13 commit on Debian 13. LMMS Vestige plugin contains offset and other GUI problems for the latest version of wine for likely similar reasons as yabridge. This is interesting because LMMS handles VST on it's own without yabridge yet exhibits very similar behavior. The latest patch also fixes offsets and other GUI issues for LMMS VSTs through Vestige. At first, the GUI offset with misaligned mouse cursor was reproduced. But after reverting back without the patch, the mouse disappeared when within the window bounds without any of the controls being responsive. I'll have to do more testing to determine if the second problem of the mouse disappearing is caused by some wine rebuild incompatibility (lmms was built from scratch pointing to custom wine build). Regardless these issues are very similar to yabridge and probably related. If one of these project's VST handling is not based on the other in some way then they both seem to have made assumptions about how Wine would handle their windowing behaviors independently. If they both made similar assumptions independently it suggests this issue's impact may be even wider for apps making similar assumptions. To reproduce on LMMS unfortunately is not very convenient at the moment. Debian apt packages don't seem to include the Vestige plugin and the AppImage at https://lmms.io/download#linux freezes upon loading a VST dll into Vestige until it throws an error about not being able to find RemoteVstPlugin.exe.so. This seems to be caused by LMMS distributing a WoW64 incompatible AppImage at the moment. It only contains 32-bit version of the file: ~/Downloads/lmms-1.2.2-linux-x86_64_AppImage/squashfs-root/usr/bin/RemoteVstPlugin.exe.so: ELF 32-bit LSB shared object, Intel i386, version 1 (SYSV), dynamically linked, BuildID[sha1]=5fd96666580c51cab41e067b0d16d0e7061c18ac, not stripped However my custom built contains a 64-bit version of the file also which fixes. This recently open issue also reports RemoteVstPlugin related issues: https://github.com/LMMS/lmms/issues/8041 Therefore I built LMMS directly from https://github.com/LMMS/lmms against the latest Wine commits. Of all the apps tested so far LMMS is the one I'm most familiar with and use regularly so I'm fairly confident everything was built properly and in working order. Maybe remaining LMMS issues should be reported separate from yabridge as related. LMMS VST issues have already been reported: https://bugs.winehq.org/show_bug.cgi?id=48527 https://bugs.winehq.org/show_bug.cgi?id=47020 https://bugs.winehq.org/show_bug.cgi?id=56935 LMMS dev recently reached out to WineHQ for assistance resolving winebuild issues: https://bugs.winehq.org/show_bug.cgi?id=58480 LMMS devs will be informed about this issue and how it relates and may impact their project. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #24 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Stian Low from comment #23)
The latest patch also fixes offsets and other GUI issues for LMMS VSTs through Vestige.
To clarify, the patch only fixes the LMMS VST offsets if the GUI is not moved and left in the original opening position. Moving the VST windows out of its original position still introduces the GUI offset mouse misalignment. It seems that either yabridge or wrapper apps like Carla call windowing updates to track window movement that works with the patch but not LMMS. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #25 from Patrick <patrick+winehq.org(a)laimbock.com> --- (In reply to Stian Low from comment #21) [snip]
Therefore it seems for virtual desktop mode the effort should be to make the VST windows all appear within the virtual desktop rather than popups appear outside it and aligned with the improperly displayed VST windows.
Maybe this commit in the yabridge new-wine10-embedding branch could help with that? https://github.com/robbert-vdh/yabridge/commit/2c6c21409c882411f0f26bcc63b64... (which also needs https://github.com/robbert-vdh/yabridge/commit/02fb140b197f3a31ed1d5ba1233e9... on top of it) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #26 from Patrick <patrick+winehq.org(a)laimbock.com> --- (In reply to Stian Low from comment #22)
(In reply to Stian Low from comment #21)
A minor bug was found which causes the knobs and hover popup labels to flicker to an offset position and back. This is showcased in the screenshot by the "Osc 2 Frequency: 3.8 semitones" label.
Typo correction: only the hover popup labels flicker and not the knobs themselves which otherwise continue to work as expected.
I have seen that flickering too. It is _very_ visible in this free synth: https://mastrcode-music.de/en/vst-plugins/t-force-zenith/ -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #27 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Patrick from comment #26)
Maybe this commit in the yabridge new-wine10-embedding branch could help with that? https://github.com/robbert-vdh/yabridge/commit/ 2c6c21409c882411f0f26bcc63b641f7df8115d8
(which also needs https://github.com/robbert-vdh/yabridge/commit/ 02fb140b197f3a31ed1d5ba1233e9261d9cbeaf0 on top of it)
Exactly what I'm seeking to prep a better patch and compare against LMMS Vestige plugin. (In reply to Patrick from comment #26)
(In reply to Stian Low from comment #22) It is _very_ visible in this free synth: https://mastrcode-music.de/en/vst-plugins/t-force-zenith/
Thanks for more links. I'll hack around a bit more with a better perspective of the latest state with previous efforts. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #28 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Stian Low from comment #23)
To reproduce on LMMS unfortunately is not very convenient at the moment. Debian apt packages don't seem to include the Vestige plugin and the AppImage at https://lmms.io/download#linux freezes upon loading a VST dll into Vestige until it throws an error about not being able to find RemoteVstPlugin.exe.so. This seems to be caused by LMMS distributing a WoW64 incompatible AppImage at the moment.
It only contains 32-bit version of the file:
Correction based on feedback from LMMS dev @tresf on their discord, nightly builds contains a WoW64 compatible version for conveniently testing their Vestige VST plugin: https://lmms.io/download#linux Apparently LMMS stable AppImage is known to be in an outdated limbo state in relation to difficulties supporting later versions of wine per @tresf comments. Reposting relevant links @tresf posted regarding LMMS Wine issues: https://forum.winehq.org/viewtopic.php?t=34128 https://github.com/LMMS/lmms/issues/7669#issuecomment-2619825120 https://github.com/LMMS/lmms/pull/7268 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #29 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Patrick from comment #26)
I have seen that flickering too. It is _very_ visible in this free synth: https://mastrcode-music.de/en/vst-plugins/t-force-zenith/
Reproduced flickering and GUI offset mouse misalignment for all wine-staging patches applied against commit 75b9e1722d1 Release 10.13 without my patch applied. Will retest wine-staging with my patch applied to confirm it still works. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #30 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 79161 --> http://bugs.winehq.org/attachment.cgi?id=79161 Patch to wine-staging applied to commit 75b9e1722d1 Release 10.13 which includes wine-staging changes to file Attached is a new patch compatible with all latest wine-staging patches applied to commit 75b9e1722d1 Release 10.13. wine-staging changes are also included in the file so only line 1682 of the patch is added based on my improved patch with rest coming directly from wine-staging. I haven't tested yet if just this patch may be applied or if other wine-staging patches also need to be installed for it to work. I will use wine-staging as the basis for prepping a better patch acceptable to wine-staging and upstream. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #31 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Stian Low from comment #30)
so only line 1682 of the patch is added
Correction: only line +1701 of the patch is added -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #32 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Stian Low from comment #29)
Reproduced flickering and GUI offset mouse misalignment for all wine-staging patches applied against commit 75b9e1722d1 Release 10.13 without my patch applied.
LMMS Vestige flickering is noticeably more resolved. Label flickering only happens occasionally but only a few times max vs continually in a loop as seen for yabridge. LMMS tests yield practically the same results for wine-staging patches as without. With my patch applied, VST windows open with correct mouse alignment but moving the window still introduces the offset unlike yabridge. Both VST handling implementations will be considered toward a wine-staging and upstream patch as they seem to fix different parts of one another. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #33 from Stian Low <wineryyyyy(a)gmail.com> --- Confirming yabridge new-wine10-embedding branch along with all latest wine-staging patches applied fixes GUI offset mouse misalignments: https://github.com/robbert-vdh/yabridge/tree/new-wine10-embedding Without the patches contained in yabridge new-wine10-embedding branch, wine-staging is still broken, proven by LMMS which appears not to have any equivalent branches/patches available with assists of WineHQ dev @rbernon as provided to yabridge. I'll let LMMS know about yabrige new-wine10-embedding branch containing WineHQ approved patched solutions as a ref for what may need to change to their Vestige VST plugin. LMMS may want to consider supporting yabridge as an additional VST handler to fallback on. Because yabrige new-wine10-embedding branch depends on wine-staging vs upstream it may be the reason why it is has not yet been merged with master nor included with distro packages yet since it would not be compatible with typical distro releases of Wine that lack staging patches. Projects like proton-ge which also depend upon wine-staging patches that may be absent from official proton release seem to be in a similar limbo state awaiting dependency staging patches to be integrated into upstream. So part of the solution to fixing these problems for more common yabridge users, is to fix whatever is preventing dependency staging changes from being merged into upstream. This latest test seems to come full circle back to where @rbernon and yabridge left off months ago. The original bug was reported directly to a Merge Request in Gitlab without a WineHQ Bugzilla which lead to some of my redundant efforts here but at least its documented now for future Bugzilla users: https://gitlab.winehq.org/wine/wine/-/merge_requests/6569 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #34 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Stian Low from comment #33)
Confirming yabridge new-wine10-embedding branch along with all latest wine-staging patches applied fixes GUI offset mouse misalignments: https://github.com/robbert-vdh/yabridge/tree/new-wine10-embedding
To clarify, none of my patches are necessary for yabridge new-wine10-embedding branch that depends on wine-staging patches. Wine-staging without yabridge new-wine10-embedding branch is still broken. yabridge new-wine10-embedding branch without wine-staging hasn't been tested because the instructions indicate that the branch requires wine-staging. Thanks to @rbernon for assisting yabridge with solutions compatible with latest upstream in-process changes. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #35 from Stian Low <wineryyyyy(a)gmail.com> --- Yabridge related bug report to WineHQ: https://github.com/robbert-vdh/yabridge/issues/409 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #36 from Stian Low <wineryyyyy(a)gmail.com> --- See @rbernon insights into remaining pending work for this issue to be closed as fixed: https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113254 Once Yabridge new-wine10-embedding branch is approved for merge to master then this issue may be considered fixed pending the relevant wine-staging changes are merged to upstream as a dependency. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #37 from Stian Low <wineryyyyy(a)gmail.com> --- Regarding recent tests by yabridge team matching latest test results posted for WineHQ: https://github.com/robbert-vdh/yabridge/issues/409#issuecomment-3206015898 I will run a test of new-wine10-embedding branch without wine-staging to determine if its actually a factor fixing this issue. Build instructions for new-wine10-embedding branch call for wine-staging according to the instructions but it may not be a blocking factor. If wine-staging is not required by fix then this issue may be considered fixed because WineHQ is not be considered blocking yabridge from upgrading because of some pending wine-staging patches in need of merges into upstream. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #38 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Stian Low from comment #34)
yabridge new-wine10-embedding branch without wine-staging hasn't been tested because the instructions indicate that the branch requires wine-staging.
Per @rbernon feedback raising doubts that wine-staging is needed vs only new-wine10-embedding branch. Confirming that yabrige new-wine10-embedding branch fixes GUI offset mouse misalignment without any wine-staging patches as dependencies despite wine-staging being recommended by build instructions. Flickering labels are still a minor issue but the major GUI offsets causing mouse misalignment are fixed. I will raise to yabridge devs the issues blocking new-wine10-embedding branch from being merged into their upstream. In the meantime, I am considering this issue to be fixed on WineHQ's end. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #39 from Patrick <patrick+winehq.org(a)laimbock.com> --- Based on my testing the offset is still there just not always. So I would not call it fixed. See https://github.com/robbert-vdh/yabridge/issues/409#issuecomment-3207331228 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #40 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Patrick from comment #39)
Based on my testing the offset is still there just not always. So I would not call it fixed. See https://github.com/robbert-vdh/yabridge/issues/409#issuecomment-3207331228
Agreed this issue should be left open for now. I reproduced your Bitwig test results which required moving the VST window to fix the GUI offset which breaks again once the window is hidden and redispayed. So far Carla/yabridge offset issues are resolved by yabridge new-wine10-embedding branch. LMMS exhibits an opposite problem to Bitwig with Vestige VST windows initially opening correctly without GUI offset which breaks as soon as the window is moved from the original position and fixed when moved back to the original position. What's unclear is whether the apps themselves contain incompatible code or if the fault lies within Wine itself. For instance, if Carla contains windowing wrapper code that is compatible with yabridge new-wine10-embedding branch but Bitwig does not it begs the question, where does the fault lie? Is it wine itself or the apps that may contain incompatible wrapping the code. I leaned toward assuming the remaining problems are related to the app wrappers because yabridge was modded for compatibility but that may be too premature an assumption. I will take a look at how Carla is wrapping VST windows to compare against other apps with available source that still exhibit GUI offset issues to clarify where the fault lies. Bitwig source doesn't seem available to compare against Carla's way of handling windows. When dealing with Windows apps, Wine hacks are valid to get apps working since they are considered black boxes with source that is not easily modded. However when dealing with Linux apps interacting with Wine, they may be treated differently preferring mods to the original source as fixes vs hacks and workarounds for Windows apps? Meaning if Linux code is considered at fault and incompatible with latest versions of Wine then it should be modded for compatibility vs Wine adding hacks to work around whatever incompatibilities. Backwards compatibility should be prioritized but it may have been considered less feasible against so many major changes made to the windowing system since 9.22. Maybe clarifying how these various apps are wrapping the windowing functionality will lead to some Wine patches that support backwards compatibility without each app needing to be modded and rebuilt for compatibility. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 Alfonso <winehq(a)alias.alfelfriki.tech> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|winehq(a)alias.alfelfriki.tec | |h | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #41 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 79175 --> http://bugs.winehq.org/attachment.cgi?id=79175 Screenshot of Windows version of LMMS via Wine instead of Linux version showcasing more minor window drag bug Windows version of both LMMS and Bitwig running through Wine do not exhibit VST GUI offsets and mouse misalignments. Thus it seems Wine may handle entire Windows versions with native VST handling compiled in better than Linux versions of those apps roll their own non-native VST handling via Wine. Bitwig issues seem mostly resolved including the control label flickering which is much rarer via Windows version on Wine. Attached is an LMMS screenshot showcasing a more minor issue of broken VST window drawing during window dragging. Bringing VST windows to the foreground clears the graphical issues. Otherwise everything seems to work as expected. Native VST handling compiled into Windows .exe may provide a level of consistency whose equivalent may not exist or be known for Wine by Linux versions to use to fix all their various VST handling bugs. Perhaps solutions may be extracted from the Windows binaries so that Wine may provide a similar level of consistency to Linux VST handlers? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #42 from Stian Low <wineryyyyy(a)gmail.com> --- Windows Carla seems to work about as well as Linux and reproduces the minor label flickering issue for Linux version: https://kx.studio/Downloads So Wine 10.13 seems to support Windows binaries of VST handlers without any wine-staging and without yabridge. Yabridge converts vst.dlls to vst.so but Wine ingests and processes the DLLs directly similar to LMMS. I will take a closer look at LMMS VST handling for Linux vs Windows diffs of build code. Maybe Windows LMMS uses a lib that handles lower level details consistently across Windows apps in a way that isn't replicated by Linux builds against Wine. This seems to prove some cross VST handler solution is mostly supported by Wine and that the remaining work is to figure out how to reproduce this solution from Windows builds to Linux builds. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #43 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 79196 --> http://bugs.winehq.org/attachment.cgi?id=79196 Screenshot of Carla Experimental features supporting VST DLLs directly via Wine without yabridge conversion to VST.so Attached is a screenshot showcasing Carla experimental features that enables loading VST DLLs directly via Wine which fixes GUI offset issues. The minor label flickering still happens but otherwise VSTs seem to work as expected without any patches or yabridge involvement. Carla VST DLL direct usage seems to place a runtime dependency on Wine that may not be the case for yabridge VST.so files converted from VST DLLs. Carla VST DLL direct usage resembles how Steam typically handles game DLLs which are used directly via Wine as a runtime dependency. There may still be use case for yabridge to convert VST DLLs to VST.so as an alternative without Wine runtime dependency. yabridge new-wine10-embedding branch patched via WineHQ assists about 6 months ago may find solutions to remaining blocking bugs via VST DLL direct usage examples. Perhaps Linux versions of VST DLL handlers are taking responsibility for windowing behavior better left to Wine window handling internals. Perhaps whatever windowing behavior Wine handles internally that corrects the offset bugs may be propagated to VST.so files in a way that does not require Wine as a runtime dependency. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #44 from Stian Low <wineryyyyy(a)gmail.com> --- yabridge uses Winelib which supports general DLL to .so conversion: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib Perhaps there is a discrepancy between how Winelib compiles in the windowing behavior vs how it runs for the Wine runtime? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 --- Comment #45 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Stian Low from comment #44)
yabridge uses Winelib which supports general DLL to .so conversion: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib
Perhaps there is a discrepancy between how Winelib compiles in the windowing behavior vs how it runs for the Wine runtime?
Echoing related: bugs.winehq.org/show_bug.cgi?id=57754#c5 Winlib doesn't seem to be a factor. Carla's experimental Wine features seems to use Python Qt vs yabridge direct XCB calls. Therefore Carla may inherit automatic windowing behaviors compatible with Wine since the 9.22 merge vs yabridge which deliberately added hacks for compatibility with Wine's broken window handling state prior to Wine 9.22. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58552 Bernhard Übelacker <bernhardu@mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |d8b5a3ae129e0971e71fcf6e953 | |87d8d1e35e646 Keywords| |regression CC| |bernhardu@mailbox.org --- Comment #46 from Bernhard Übelacker <bernhardu@mailbox.org> --- From comment #10, adding regression keyword and commit sha1. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla