Re: [fluid-dev] New Reverb and Chorus API versus actual API

[Marcus Weseloh]

Hi JJC,

Am Do., 17. Sept. 2020 um 11:52 Uhr schrieb Ceresa Jean-Jacques
<jean-jacques.ceresa@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