Live data from Hacker News

Let's Write a Reverb (2021)

signalsmith-audio.co.uk

61–65 of 65 posts

Re: Let's Write a Reverb (2021)

#61
FTA: There are some interesting designs here - and they work, but they often require careful tuning. As well as finding a good compromise for the delay time, using too much inter-channel mixing can lock the delays together so they act like a cohesive unit, which isn't great for longer tails.

Made me wonder whether there’s a connection with linear feedback shift registers (https://en.wikipedia.org/wiki/Linear-feedback_shift_register)

If you have a LFSR that produces a decent but not too good pseudo-random signal, can you use its parameters to create a decent reverb?

Re: Let's Write a Reverb (2021)

#62
post #48

Is there a way to get "realistic" reverb using GPU computation?

I think a GPU is overkill. In the guitar world, there are dozens of insanely high quality reverb pedals and they all only have some basic chips in them, no GPU necessary.

No, but the question bears discussion. Many of us have high powered GPUs in our machines that sit idle during audio production. Could they be leveraged? Not just for reverb.

Re: Let's Write a Reverb (2021)

#63
post #53

Earlier quoted context omitted.

It is 100% possible and there are a slew of tricks you can use to get big performance boosts with negligible cost to accuracy.

Do you know what the tricks are?

1. Don’t use LSTMs (4 vector-matrix multiplies) or GRUs (3 multiplies). Use a fixed Hippo matrix to update state. Just 1 multiply and since it’s fixed you can unroll during training, much faster than backprop through time.

2. Write SIMD intrinsics by hand. None of the libraries are as fast.

3. Don’t use sigmoid or tanh functions as your nonlinear activation. Instead approximate them with the softsign function which is much cheaper.

Depends on exact architecture, but these optimizations have yielded 10-30x improvement for single threaded CPU real time audio applications.

When GPU audio matures all this may be unnecessary.

Re: Let's Write a Reverb (2021)

#64
post #48

Is there a way to get "realistic" reverb using GPU computation?

My understanding is that latency is usually a much bigger concern than raw computing power when doing audio processing. GPUs are great at doing large batches of computation, but aren't as good at doing lots of small batches with low latency, which is what audio processing tends to be.

Re: Let's Write a Reverb (2021)

#65
I have a Yamaha FX-500 multi-effects processor from 1989.

Original owner; got it in 1989.

I was fiddling with it recently to try to get a decent reverb. The main algorithms don't sound good; they have not aged well. These algorithms have a delay parameter, but it doesn't produce enough of a separation somehow.

Instead of a reverb-only block you can choose a combined delay with reverb (R->D, D->R or D+R). The delay block takes its own resources, leaving fewer for the reverb, which is simplified. You cannot choose the type of reverb (plate, hall, ...) and there are fewer parameters.

The interesting thing is that with the D->R and R->D, I can get much better sounds.

The D->R can produce a pretty lush/deep long reverb, where the main signal stands out clearly.

(I should mention that I'm using an external analog mixer for mixing the dry signal: the FX-500 is 100% wet. Thus, in general, I can get the best possible sound out of it: the full resolution is allocated to the effect, not to propagating the dry signal.)

Less can be more; a simpler reverb can sound better. A completely separate delay before the reverb can be better than playing games with built-in pre-delay.

Basically, in combining the resources of the delay and reverb into a more complicated reverb effect, Yamaha somehow made a mess.

Post reply on HN