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

[Tom M.]

> My guess is that most users simply use a single stereo output from
FluidSynth.

Probably. And I must admit that I'm still not convinced that it makes
sense from a musically perspective to control all effects groups
independently. However, I understand the technical need for it, so I'll
buy it. [The other change about the buffer mapping we still have to
discuss and "design". I haven't forgotten.]

> The proposed new API functions simply add a "2" to all names.

That was my proposal. I find it hard to find a suitable naming
convention for those new functions. Initially we had
fluid_synth_set_fx_reverb_roomsize(). Now you're suggesting
fluid_synth_set_reverb_unit_roomsize(). However, the corresponding
setting is named effects-groups. And: do we add this "magic word" (unit,
fx, group,...) before or after the "reverb" word? ...Pretty confusing.
Simply adding a 2 is easier to write, easier to remember and consistent
with a few other places among our API (new_fluid_sequencer,
new_fluid_audio_driver), I think.

While I agree that the existing API functions should be kept, I would
still vote for their deprecation. I see this deprecation notice as an
advice to developers to use those new functions in new code instead. Yes
I get your point with the -1 catch all. I don't think it would hurt to
make developers think about that in new application. In any case, I'm
open which way to go here. Just let me know if you insist.

However, I vote against introducing new shell commands. Instead, the
existing commands, should become smart enough to detect whether they
have been called with one or two parameters. If only one: the old
behaviour takes place. If two, the user wants to apply the change only
for the given fx unit, e.g.:

rev_setroomsize [fxid] num

Side note: those existing shell commands have already been deprecated.
Ofc. this should be reverted once this feature will be implemented.

Tom