November 2023 - wine-gitlab

[PATCH v3 0/6] MR461: vkd3d: Implement ID3D12Device2::CreatePipelineState().
by Conor McCarthy (＠cmccarthy) 14 Nov '23

14 Nov '23

-- v3: vkd3d: Support depth bounds test. tests: Test CreatePipelineState(). vkd3d: Implement ID3D12Device2::CreatePipelineState(). vkd3d: Use struct d3d12_pipeline_state_desc for compute pipelines. vkd3d: Introduce struct d3d12_pipeline_state_desc for graphics pipelines. include: Add a D3D12_RT_FORMAT_ARRAY typedef. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/461

3 9

Re: [PATCH v2 0/7] MR4375: dmsynth: Various fixes 2
by Rémi Bernon (＠rbernon) 14 Nov '23

14 Nov '23

On Tue Nov 14 10:43:53 2023 +0000, Anton Baskanov wrote: > DLS2 spec has a table of fixed routing connections that must be > supported, but also mentions that implementations are free to support > other connections as well. > Imagine a DLS file that has a SRC_KEYNUMBER->DST_EG1_DECAYTIME > connection with a controller. It would require a dynamic offset > adjustment based on the controller value. And there could be multiple > such connections, each with a different controller. Hmm, right but does FluidSynth support such things? I had the impression (but haven't confirmed it in any way) that they have dedicated generators for some often used connections and that these were not supposed to be set through fluid_mod. So, under that assumption a custom connection to link SRC_KEYNUMBER -> DST_EG1_DECAYTIME would not be possible to map? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4375#note_52212

1 0

Re: [PATCH v2 0/7] MR4375: dmsynth: Various fixes 2
by Anton Baskanov (＠baskanov) 14 Nov '23

14 Nov '23

On Tue Nov 14 10:00:34 2023 +0000, Rémi Bernon wrote: > What do you mean by arbitrary connections? DLS2 spec has a table of fixed routing connections that must be supported, but also mentions that implementations are free to support other connections as well. Imagine a DLS file that has a SRC_KEYNUMBER->DST_EG1_DECAYTIME connection with a controller. It would require a dynamic offset adjustment based on the controller value. And there could be multiple such connections, each with a different controller. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4375#note_52209

1 0

[PATCH v2 0/1] MR4350: rpcrt4: Remove DECLSPEC_HIDDEN usage.
by Alistair Leslie-Hughes (＠alesliehughes) 14 Nov '23

14 Nov '23

-- v2: rpcrt4: Remove DECLSPEC_HIDDEN usage. https://gitlab.winehq.org/wine/wine/-/merge_requests/4350

3 2

Re: [PATCH v2 0/7] MR4375: dmsynth: Various fixes 2
by Rémi Bernon (＠rbernon) 14 Nov '23

14 Nov '23

On Tue Nov 14 09:21:35 2023 +0000, Anton Baskanov wrote: > > 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). > ![Screenshot_20231114_155825](/uploads/e46a2662792a0452350b8384b7eea0a6/Screenshot_20231114_155825.png) The attack time looks different but were it the same I think the shape difference can be ignored by having some leeway in the test. I added a couple of similar tests for MF audio transform output where we check that the total sample diff does not exceed a small percentage of the total, maybe reusing it here can work. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4375#note_52207

1 0

Re: [PATCH v2 0/7] MR4375: dmsynth: Various fixes 2
by Rémi Bernon (＠rbernon) 14 Nov '23

14 Nov '23

On Tue Nov 14 09:21:35 2023 +0000, Anton Baskanov wrote: > 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. What do you mean by arbitrary connections? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4375#note_52206

1 0

[PATCH 0/1] MR472: vkd3d-shader: Add a helper to check for a numeric type.
by Nikolay Sivov (＠nsivov) 14 Nov '23

14 Nov '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/472

3 2

[PATCH 0/1] MR4367: winmm/tests: Use calloc instead of HeapAlloc.
by Alex Henrie (＠alexhenrie) 14 Nov '23

14 Nov '23

Fixes: bb6bcaf83e91882e0a523a4455ed7174b3ce3ad4 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4367

3 2

Re: [PATCH v2 0/7] MR4375: dmsynth: Various fixes 2
by Anton Baskanov (＠baskanov) 14 Nov '23

14 Nov '23

> 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). ![Screenshot_20231114_155825](/uploads/e46a2662792a0452350b8384b7eea0a6/Screenshot_20231114_155825.png) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4375#note_52200

1 0

Re: [PATCH v2 0/7] MR4375: dmsynth: Various fixes 2
by Anton Baskanov (＠baskanov) 14 Nov '23

14 Nov '23

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

1 0

2025

2024

2023

2022

wine-gitlab November 2023