On Tue Nov 14 11:01:46 2023 +0000, Rémi Bernon wrote:
> 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?
Looking a bit more into FS, it seems possible that it actually supports this, with fluid_voice_modulate updating generators "mod" value (used in fluid_voice_gen_value return) and calling fluid_voice_update_param, which calls calculate_hold_decay_buffers.
In this case would it be simpler for our mapping to use mods for everything instead of setting it through these special generators?
Anyway, for the fixups I think we could have a list of `fluid_mod` to apply like this, using `fluid_mod_test_identity` to replace identical mod entries:
```c
struct mod_entry
{
struct list entry;
fluid_mod_t *mod;
};
```
And if we can use mods for most generators, I can even imagine having an additional `int mode` field to keep at most one `FLUID_VOICE_OVERWRITE` and one `FLUID_VOICE_ADD` mod of each, translating and de-duplicating / fixing up all articulations at once, then adding the resulting mod list to the voice in a separate step.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4375#note_52231
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
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
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).
> 
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
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