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.
-
Rémi Bernon (＠rbernon)