[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] New Reverb and Chorus API versus actual API
From: |
Marcus Weseloh |
Subject: |
Re: [fluid-dev] New Reverb and Chorus API versus actual API |
Date: |
Sun, 11 Oct 2020 12:22:44 +0200 |
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
- Re: [fluid-dev] New Reverb and Chorus API versus actual API,
Marcus Weseloh <=
- Re: [fluid-dev] New Reverb and Chorus API versus actual API, Ceresa Jean-Jacques, 2020/10/14
- Re: [fluid-dev] New Reverb and Chorus API versus actual API, Tom M., 2020/10/18
- Re: [fluid-dev] New Reverb and Chorus API versus actual API, Ceresa Jean-Jacques, 2020/10/18
- Re: [fluid-dev] New Reverb and Chorus API versus actual API, Marcus Weseloh, 2020/10/20
- Re: [fluid-dev] New Reverb and Chorus API versus actual API, Ceresa Jean-Jacques, 2020/10/20
- Re: [fluid-dev] New Reverb and Chorus API versus actual API, Tom M., 2020/10/20
- Re: [fluid-dev] New Reverb and Chorus API versus actual API, Marcus Weseloh, 2020/10/20
- Re: [fluid-dev] New Reverb and Chorus API versus actual API, Ceresa Jean-Jacques, 2020/10/23