Forums > MaxMSP

emulating Live's reverb "freeze" function?

October 9, 2013 | 2:15 pm


So as far as I understand it, "freeze" on Live’s reverb basically starts a full 100% feedback loop inside the reverb.

Do any of you have any experience with treating reverbs like that inside max? I sometimes do some trickery with large racks of live reverbs, but I’m looking to port those into a dedicated device.

October 9, 2013 | 10:12 pm

There’s a gen patch out there that does it. I think it was called foreververb?

I’ve built patches like these using parallel feedback delays. I do it with three delays per freeze, with relatively prime times. Set feedback to 100%, and ramp up and then down input to capture.

I use one rand~ as an amp lfo on each loop. (I rhink I scale it so it doesn’t go theough zero) This really helps to break up the texture.

All of this is wrapped in a poily~. The reverb approach will of course be smoother, but it will take up more CPU. (Though down sampling could help)

October 10, 2013 | 1:17 am

it is as simple as you think: set the feedback to 0.9999 and the input to 0.0 … frozen. :)
or in other words, it should work with most reverb patches.

if you want to exlude or include the first reflections is a matter of taste. including them can become very ugly when freezing for longer than a quarter of a second, but otoh leaving them in reproduces the phase/room feeling of the normal reverb a a bit more.

October 11, 2013 | 12:53 am

thanks guys, nice to know I wasn’t completely off base :)

@peter thanks for the relative prime tip, wouldn’t have thought of that straight away, so that helps :) – I’ve made a "delay time complicator" that multiplies by freaky floats, should work alright. – like, for instance, having a 2 3 5 ratio, you’re still going to get coinciding delays at 6 and 10 quite quickly on a "forever" feed.

@roman thanks, I’m trying to strip some things I have way down first, then I’ll give a simple three-delay thing a go. The thing I love about using reverb freezes is that it seems to capture the "essence" of the input sound quite well.

October 11, 2013 | 12:56 am


I would be interested to see the fruits of your labour on this


October 11, 2013 | 4:40 am

The key for the triple delay approach (and it works best on sounds with a steady state) is to fade the sound in after its attack so you don’t have a bunch of transients in a rhythmic loop.

It’s not as even as a proper reverb, but can work well with careful tuning. Also, since it’s usually less complex, you can run a lot more of them. I do them in a poly~ so I can bring individual ones in and out.

October 11, 2013 | 5:22 am

I’ve always used freeverb/freeverb~ for this, and there’s a treasure trove of reverb related stuff at the freeverb3 sourceforge page – – maybe something in there might help?
(ironically, the latest versions of freeverb don’t seem to have the ‘freeze’ function any more)

October 11, 2013 | 7:47 am

@roger aah, so the old version may be more hackable for this… interesting!
@peter yeah, I’m hoping to cluster these together so that I don’t get any rhythmic information coming through – I may just up the delay amount a bit, too.

What I’ve done is instead of doing 3 taps on tapout~ I’ve set up three discrete delays and feedback lines, looking forward to doing some testing on this today.

@Brendan :) I’ll keep posting what I’ve got here… especially since I may end up needing help to poly-ize this properly :headdesk: hehe.

October 11, 2013 | 9:59 am

A while ago I experimented with a Schroeder network in gen~, that quite quickly led to fairly good results, including eternal reverb or freezing effect. (Please don’t ask me to share the code, in this case I cannot.)

  1. RevNetwork


  2. Schroeder


October 11, 2013 | 11:35 am

ah, very nice, that’s simple enough.

What does the "krt" mean in the diagram, by the way?

October 11, 2013 | 12:08 pm

2 3 5 is a valid example for primes but not perfect for first reflections.

allpasses at 1./17. 1./29. 1./41 should sound much less metallic. :)


October 11, 2013 | 12:12 pm

Yeah, the prime part only matters in relationship to each other..maybe better expressed as "minimize the GCD"

October 11, 2013 | 12:20 pm

be careful to substract one time the vectorsize from the third delay (or from the first)

October 11, 2013 | 1:58 pm

can you elaborate, Roman? I have no clue what you’re talking about :)

October 11, 2013 | 2:39 pm

so yeah, this does the basic freezy goodness, but I’m a bit stumped on the diffusion – the delay itself still gets… tonal, metallic, whatever you want to call it?

Any idea on how to approach that part of it? I was thinking that doing some feedback between the delays would work, like in the algo posted above, but if there were specific guidelines I’d love to hear it. I’ll be experimenting with allpasses and such in the interim :)

thanks, gang.

oh and here’s the simple basic "freeze an input" patch:

— Pasted Max Patch, click to expand. —


October 11, 2013 | 3:46 pm

what i mean is … feeding back introduces a change to the desired delay times … not sure if it applies. :)

October 12, 2013 | 12:17 am

@wetterberg Krt controls reverb time. But when you implement the RevNetwork as the All-Pass Reverberator in the other scheme, you don’t need Krt. That image comes from

October 13, 2013 | 12:05 pm

Is KRT a gain stage?

October 13, 2013 | 3:28 pm

krt. krt. krrrrrt.

krt bumm.

October 13, 2013 | 4:52 pm

Is KRT a gain stage?

yeah, that’s what I’m wondering; not what it does in the algorithm, but which mathematical function it represents.

October 13, 2013 | 5:17 pm

reverb time is usually controlled by the feedbacks amplification …

Viewing 21 posts - 1 through 21 (of 21 total)

Forums > MaxMSP