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