Audio Effect Reverb

[gamblor21]

Adding a reverb effect for audio effects, based on FreeVerb.

Question:

1. Should this be the final location for the effect (audiodelays)? Early on we debated more modules but I'm not sure if there is value to make a Reverb only one.

Time permitting I may still add in a way to control dry and wet mix independently. So mix could either be mix=0.5 or mix=(0.3,0.3)

[gamblor21]

@relic-se If you have a moment this is ready for testing. No rush.

[relic-se]

Great work so far! I haven't dug into everything quite yet, but the biggest issue at the moment is definitely the mix implementation. <0.5 doesn't seem to work for me.

All my testing was on an RP2040 with mono 22050hz sample audio (StreetChicken.wav).

[relic-se]

I haven't quite figured out why, but when mix is <0.5 (ie: 0.499999), there is no effect at all in the output. When mix is 0.5+, then the effect is at full volume and the sample volume decreases as you approach 1.0. The implementation in audiodelays_reverb_get_mix_fixedpoint appears correct.

[relic-se]

Should be spelled "reverberant", but also I feel that this description isn't precise. A higher value "dampens" the high frequency response and reduces reverberation among those frequencies (lower frequencies aren't affected as much).

[gamblor21]

Reworded it.

[relic-se]

As for comments on your questions, I think it is fine to keep reverb in audiodelays. Although it is filter-based, it is mostly associated with delay, and it is unlikely at the moment for us to add multiple reverb-based effects in to warrant a dedicated audioreverbs module (but I am a fan of spring reverb...). It can always be moved around in a future release if need be.

Okay, I may have changed my mind. What if we did create a new audioreverbs module, renamed this effect to "RoomReverb" or "Freeverb". Then, we could aim for "SpringReverb" and "PlateReverb" additions in the future? I'm not certain exactly how those would work or if they're feasible for the target platforms, but it would definitely give us sufficient variety. Other potential reverb types could be "ReverseReverb" and "Flerb" (has a "flanging" sound).

Unless you want to take a swing at allowing independent dry/wet mix control globally, I vote we keep it standardized for now and then expand all effects in the future to support this functionality. This question might be better poised on a separate issue/PR, but how would you handle BlockInput support in that scenario?

[gamblor21]

Okay, I may have changed my mind. What if we did create a new audioreverbs module, renamed this effect to "RoomReverb" or "Freeverb". Then, we could aim for "SpringReverb" and "PlateReverb" additions in the future? I'm not certain exactly how those would work or if they're feasible for the target platforms, but it would definitely give us sufficient variety. Other potential reverb types could be "ReverseReverb" and "Flerb" (has a "flanging" sound).

@tannewt @dhalbert Any preference on keeping the reverb in audiodelays vs making a new audioreverbs? We had talked about a new module for them previously. Or we could always create these effect for now and move it later?

[dhalbert]

The advantage of a separate module is that we can turn it off if there are space problems. So I don't think it's bad. Didn't we have audioeffects for a while but it became too big?

As for further reverbs, how different are they in terms of code? Could you make a parameterized reverb that handles all of those in a single class with parameters, or is there something different in the calcuations?

[relic-se]

The advantage of a separate module is that we can turn it off if there are space problems. So I don't think it's bad. Didn't we have audioeffects for a while but it became too big?

There was never a singular audioeffects module to my knowledge since we moved to separate modules in initial talks. Nonetheless, I am in agreement.

As for further reverbs, how different are they in terms of code? Could you make a parameterized reverb that handles all of those in a single class with parameters, or is there something different in the calculations?

Unfortunately, I think other reverb types will operate very differently. The reverb algorithm implemented here, "Freeverb", is finely-tuned for its particular operation (a general "room" sound). Further research may dispute this.

[tannewt]

I'd go further and put this in a freeverb module (check pypi to make sure it doesn't exist). That way each reverb implementation can have its own module and inclusion.

[gamblor21]

Unless you want to take a swing at allowing independent dry/wet mix control globally, I vote we keep it standardized for now and then expand all effects in the future to support this functionality. This question might be better poised on a separate issue/PR, but how would you handle BlockInput support in that scenario?

I think I may leave it and get this PR in and we can look at how to handle mix better across the board later. I think for BlockInput on separate wet/dry I'd just let them vary and and maybe with a caveat if you got 1.0 and 1.0 then yes your audio volume could double. Direct people to the mix=0.5 but have an advance mode that basically we take the guard rails off.