This pull request fixes Wine's MIDI synthesizer reset process to be the same as Windows'.
When playing Touhou Project games in MIDI BGM mode, the music playback becomes buggy when the BGM changes.
The video below is an example of an anomaly that occurs when playing The Fantastic Tales from Tono after playing Crystallized Silver in Touhou 7.
https://youtu.be/O69sndJ45Ag
Here's a correct example of The Fantastic Tales from Tono playback:
https://youtu.be/XlFAQEbbNDg
Piano sound is clearly missing on Wine.
This issue occurs due to an Wine's incorrect reset process for MIDI synthesizer.
When I ran FluidSynth on Windows and checked the log, I found that CC123 and CC121 were executed for each MIDI channel when switching songs.
CC123 means All Notes Off, CC121 means Reset All Controllers.
--
v6: Corrected the comment.
wineoss: Send All Notes Off and Reset Controllers.
winecoreaudio: Send All Notes Off and Reset Controllers.
winealsa: Send All Notes Off and Reset Controllers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8808
Commit 518e394794160818ffe6826c874ff2f550c95bbb introduced new and important default behavior for PE binaries built using `winegcc`/`wineg++`/`winebuild`.
* `/DYNAMICBASE` - Generates an executable image that can be randomly rebased at load time by using the address space layout randomization (ASLR) feature of Windows that was first available in Windows Vista.
* `/HIGHENTROPYVA` - Randomized 64-bit virtual addresses make it more difficult for an attacker to guess the location of a particular memory region.
... however as identified in https://bugs.winehq.org/show_bug.cgi?id=58480, this new default behavior can severely impact applications that interact with binaries created for Windows XP and older. This is quite common for legacy audio plugins, such as VST2(TM) plugins.
This MR keeps the new default "dynamicbase" and "highentropyva" flags by default, but mirrors the mingw/msys2 `--disable-dynamicbase` flag as explained here: https://www.msys2.org/news/#2021-01-31-aslr-enabled-by-default. MSVC also provides a similarly named flag [here](https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase).
Downstream, the LMMS project has successfully deployed the mingw flag and the MSVC flag for our Windows builds. Our Linux builds use a custom wine-bridge and would benefit from the same.
We've currently tested this MR downstream against a snapshot of master branch to passing results.
Downstream PRs:
* Linux: https://github.com/LMMS/lmms/pull/7987
* Windows: https://github.com/LMMS/lmms/pull/7976
--
v9: winebuild: Add flag to disable dynamicbase/aslr
https://gitlab.winehq.org/wine/wine/-/merge_requests/8786
Under Windows and the PID specification it is possible to specify less than the full set of condition blocks. Under SDL and the Linux FF input API all condition blocks must always be specified.
The existing code does not set any values outside the specified axes. This effectively sets the strength to zero along these axes. Testing setting just one axis with the MS Sidewinder 2 under Windows, however, reveals that revealed that it sets the first axis (the X-axis) to the given parameter values and sets the other axis to full strength (this is most easily felt/tested with the spring effect).
This sets unspecified axes in the SDL and udev input backends to play at full strength to agree with Windows. It also updates joy.cpl to play condition effects along the indicated axis too.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8824
Summary of: https://bugs.winehq.org/show_bug.cgi?id=58552#c42
Windows versions of various audio apps handle VSTs better than Linux versions.
This seems further prove that this merge request is valid despite bug reports against it.
The more I review the more it seems this merge fixed bugs that made buggy code run in a less obviously buggy way.
Thus it seems this merge may have helped expose fixes needed by Wine dependent VST projects.
Yabridge fixes seem mostly fulfilled per new-wine10-embedding branch testing for vanilla-wine. But yabridge new-wine10-embedding still is not merged with upstream yet because of other reported issues caused by this merge.
I will suggest to all reporters to test Windows versions of audio apps if available to confirm VST handling is improved. If most apps report improvements then it may suggest a common Windows lib is taking care of the lower level window handling details that so far have been difficult to replicate on Linux.
With Windows versions proven to improve VST handling, Windows vs Linux build details around VST handling may reveals whatever Windows component provides the consistency across Windows version to be replicated for Linux builds.
If Wine is able to handle VST natively then it may eliminate the need for yabridge translation of vst.dll to vst.so. LMMS already ingests VST DLLs directly and may already be on the right track for VST DLL handling directly through Wine.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113700
@rbernon had also noticed that under the SDL backend, effects with a direction of mostly right with a bit of up played mostly up/down and not right/left as would be expected.
Traced this down using a `INT16` for the rotation angle in the SDL backend, which isn't large enough to represent 36000. Overflowing would effectively subtract 66536, amounting to a 65536 % 36000 = 29536 centi-degree rotation. End effect was effects mostly right with a bit of up (those over 327 degrees) where changed to mostly up with a bit of right (rotated counter-clockwise 65 degrees).
This patch changes the local computation variable to INT32, which also matches what is used by the SDL library.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8780