> Although they look fine, 20ab5954 (and ec219ce1 even more) cut some notes early in FF VIII intro.
Looks like note-off queuing for DMUS_PMSGT_NOTE needs to be handled differently. I'll drop these for now.
> Haven't really looked into the details but 0ff26da7 feels a bit complicated, I'm wondering if there's a better way to do this.
It depends on whether we need to support arbitrary connections.
> Regarding 2e226c26, is this what native does?
Yes, there is no fallback for melodic instruments for some reason, only for drums. Though now I see that I handle missing regions incorrectly (these should also fall back to Standard). I'll update the request.
I was also thinking about adding some tests, though I'm not sure how to compare the output. The generated waveforms are quite different (e.g. native produces a linear attack slope with some discrete steps, while FluidSynth produces a smooth exponential one).

--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4375#note_52200
On Mon Nov 13 13:16:56 2023 +0000, Rémi Bernon wrote:
> Instead of a dynamic list, could we have just a simple structure like:
> ```c
> struct gen_increments
> {
> float env_hold;
> float env_decay;
> float vol_hold;
> float vol_decay;
> };
> ```
> Which we would pass around down to `add_mod_from_connection` which would
> set the needed adjustments (it's actually only needed there,
> `set_gen_from_connection` won't have to add increments), and then after
> the loops we would call `fluid_voice_gen_incr` for each of these?
> Or do we need the generic version for more fixups that are not in this MR?
If we don't need to support arbitrary connections, then yes, your proposed solution looks like the way to go.
I don't currently plan to add more fixups.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4375#note_52199
`sysconf(_SC_PHYS_PAGES)` returns an error for i386 Mac binaries on any machine with more than 4 GB of RAM. From [the source code](https://github.com/apple-oss-distributions/Libc/blob/c5a3293354e22262… it's clear why--it calls `sysctlbyname()` to put the `hw.memsize` sysctl into a long, which is only 32-bits on i386. This returns an error on any Mac with more than 4GB: the value is too large for a 32-bit long.
The `sysctl` man page documents that an int64 should be used for `hw.memsize`, do that and divide by the page size ourselves.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4384
On Mon Nov 13 21:02:03 2023 +0000, Alexandre Julliard wrote:
> > Well, I target the parts where the folders are created, where else
> could I handle it? I currently don't see a better way to do this. Mind
> pointing me into the direction of a better design?
> I don't mean the code, I mean the UI design.
> As you point out, this can be configured from winecfg. So why do we need
> a separate mechanism, with an ad-hoc environment variable? Why is it
> only usable at prefix creation? Is there a way to unify the features, or
> make them easier to use? How is it different from `winetricks sandbox`?
> etc. etc.
Not sure this is the right place to discuss this, but the problem with winecfg is that the config is stored inside the WINEPREFIX. Every new WINEPREFIX would need to be configured again, since you (currently) can't have a global config. Similar issue with `winetricks sandbox`, you need to remember to do it in every new WINEPREFIX. I'm testing a lot of applications, and they often tend to put files into Documents and similar folders, and I want to prevent that. But since I regularly delete my WINEPREFIX, that config currently can't be permanent.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3259#note_52188
--
v10: vkd3d-shader/spirv: Avoid invalid bool-to-bool conversion in spirv_compiler_emit_movc().
vkd3d-shader/dxil: Implement the DXIL VSELECT instruction.
tests/shader-runner: Add tests for 64-bit casts.
vkd3d-shader/spirv: Return an error if an invalid handler is encountered.
tests/shader-runner: Add a test for float comparisons.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/459