Convolution reverb - independant wet/dry controls for each channel

I’m going to want to have independent left/right (and potentially rear left/rear right as well) wet/dry control of the convolution reverb at some point in the not so far away future.

At the moment it seems like the only way to do this is to split the signal into separate channels, or returns, with forced mixing and panning of the signals which aside from the added complexity needs additional instances of the convolution DSP.



That’s an interesting request! I’ll add your suggestion to our feature/improvement tracker.

I’m a little curious, though: Why do you want to apply convolution reverb on a per-channel basis?

Not necessarily. If you use a send and a couple of channel mix effects, you could do it with just one convolution reverb effect, saving a considerable amount of resources. It would still take some time and effort to set up, though.

Imagine being in a car, using the convolution plus an additional multiband for the cabin ‘sound’ and using automation for “winding down a front left window, or a rear right window - or potentially losing a door” (or a hatchback boot).

The filtering would be less, but will still bleed to some of the other speakers (in which case using the pan may still be required to control the bleed positioning.

I’ve played around with a couple of ways to do this, and haven’t got the results I like so far. Partly because send/return adds a very small bit of latency, and the convolution is as much about being an EQ as much as a reverb, and I don’t want latency on an EQ.

Ah, I see! You wouldn’t be able to rotate the camera independently of the car and preserve the effect, but since so many car-based games fix the camera to the vehicle, I can see how that could be useful. I’ll add that context to the entry in our feature/improvement tracker.

Have you considered using sends for both the wet and dry signals? The latency introduced by a send is fixed, so if there are the same number of sends in each signal path, there’ll be no difference in latency between them.

Of course, if you’re trying to avoid latency entirely this won’t solve the problem, but if your goal is to avoid a difference in latency between the wet and dry signals, it will work.