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

[Marcus Weseloh]

Am So., 11. Okt. 2020 um 14:29 Uhr schrieb Tom M. via fluid-dev
<fluid-dev@nongnu.org>:
> > 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.

Yes, I completely understand. And I had forgotten (or overlooked) the
other naming proposals. I still think as a long time solution, having
meaningful names for API functions is way better than simply adding
"2" to the end. Especially if we plan on deprecating and eventually
removing the original functions. Because then we are left with an API
that contains some functions ending in "2", with no clear indication
why they are named like this. Unless you plan on another deprecation
round and then removing the "2" again at a later date, of course.

So I would still vote to go with a "future-proof" name for the new
functions, something like "fluid_synth_fx_set_..." or
"fluid_synth_set_fx_..." or "fluid_synth_set_reverb_unit_...".
I actually feel more strongly about the naming than about the
deprecation of the old API functions, to be honest. In my mind, API
functions and shell commands target quite different audiences. API
functions are always for programmers... and we can expect programmers
to read the API documentation and understand what an fx unit is and
how it relates to multi-channel vs. single-channel output. So forcing
them to always specify an fx unit index or -1 as a catch-all would be
ok, I guess.

> 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.

Good idea! Not perfect in my opinion, as the documentation for those
commands would still need to show the optional fx unit param,
triggering "normal" users to wonder what they are... but a good
compromise. In any case, much better than removing the old commands
and forcing everybody to specify a magical -1 for those functions.

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

Ah, I wasn't aware of that. What was the reason for deprecating those
shell commands?

Cheers
Marcus