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 _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
