It would be great if we could unify these approaches so that everything is available everywhere. It seems to me like the settings is the most competent one here, and they are read/write from both command line and shell.
So how about turning the reverb parameters into settings?
Oh ... I just realised that there is a -o parameter to define a "setting". I didn't realise that settings (in general) were settable from the command-line, nor that the four reverb parameters are *not* settings. I suppose that means if you want to change them via the API, you can't use settings (as I suggested), but instead you must manually figure out which function to call (fluid_synth_set_reverb). I agree, it would be nice if reverb (and chorus, and probably some other things) were turned into settings.
It could mean we could deprecate APIs like fluid_synth_set_reverb (in favour of settings) as well as command-line commands like rev_setroomsize (in favour of set synth.reverb.roomsize).
That would solve my problem, because I could then use -o synth.reverb.roomsize=0.8. But it still wouldn't let you have a separate "settings file" (if you had a lot of these) to pass to FluidSynth in -F or other times when it won't read from stdin. So I would still like the ability to supply a settings file on the command line (not via stdin). Once reverb is a setting, there are two possibilities for this:
1. Make this file simply a command script that is fed to the command-line interpreter just as if it was send via stdin (as I suggested above), or
2. Make this file a true settings file, which consists of key=value pairs and # comment lines, which modifies the settings.
As long as there are settings to cover all the things you might want to change (e.g., reverb), then I don't see a problem with #2 and I think it would be cleaner.
Hence: There are two separate issues. a) Reverb and chorus (and while we're at it, anything else?) need settings, and b) A way to pass a settings file to FluidSynth without using stdin.
Matt