emulating Live's reverb "freeze" function?
Hey,
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.
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)
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.
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.
@Andreas
I would be interested to see the fruits of your labour on this
Brendan
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.
I've always used freeverb/freeverb~ for this, and there's a treasure trove of reverb related stuff at the freeverb3 sourceforge page - http://freeverb3.sourceforge.net - maybe something in there might help?
(ironically, the latest versions of freeverb don't seem to have the 'freeze' function any more)
Cheers
Roger
@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.
ah, very nice, that's simple enough.
What does the "krt" mean in the diagram, by the way?
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. :)
-110
Yeah, the prime part only matters in relationship to each other..maybe better expressed as "minimize the GCD"
be careful to substract one time the vectorsize from the third delay (or from the first)
can you elaborate, Roman? I have no clue what you're talking about :)
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:
what i mean is ... feeding back introduces a change to the desired delay times ... not sure if it applies. :)
@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 http://www.spinsemi.com/knowledge_base/effects.html#Delay_effects.
Is KRT a gain stage?
krt. krt. krrrrrt.
krt bumm.
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.
reverb time is usually controlled by the feedbacks amplification ...