Hi JJC, Am Do., 17. Sept. 2020 um 11:52 Uhr schrieb Ceresa Jean-Jacques <jean-jacques.cer...@orange.fr>: > To overcome this issue a new set of Revert and Chorus API will be proposed > with one added parameter which is the fx unit index (0 or 1) > to which the change is applied. This new API set can also behave like actual > API set if fx unit index is -1. > That means that the actual API set will become redundant as soon the new API > set will be proposed. > So it seems that it should be preferable to deprecate the actual API set > (that should be replaced by the new API set). > Now the question is: does the deprecation of actual Reverb and Chorus API > could cause issues ?
My guess is that most users simply use a single stereo output from FluidSynth. And that most users will not even be aware that FluidSynth has support for multi-channel output, let alone support for multiple fx units. So based on that assumption, I would vote against deprecating the existing API and shell commands. Otherwise we would force users who have no interest in multi-channel output or multiple fx units to think about which fx unit they want to target. I know there is the -1 catch-all, but that is still another "magic" parameter to those functions that users need to think about. The proposed new API functions simply add a "2" to all names. Maybe we could name the new functions differently to make their intended use more clear? So instead of "fluid_synth_set_reverb_roomsize2" we could name it something like "fluid_synth_set_reverb_unit_roomsize". That might make it clear that those functions target a particular unit. And then remove the -1 catch-all, as we still have the old API around if you want to target all existing fx units. Same for the shell commands: keep the old commands like "rev_setroomsize" unchanged, then add new commands like "revunit_setroomsize". TLDR: I am against complicating the common use-cases for a rarely-used special use-case. Adding new API functions and shell commands for the special case and keeping the existing API unchanged sounds better to me. Cheers Marcus _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
