emulating Live's reverb "freeze" function?

    Oct 09 2013 | 9: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.

    • Oct 10 2013 | 5:12 am
      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)
    • Oct 10 2013 | 8: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.
    • Oct 11 2013 | 7: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.
    • Oct 11 2013 | 7:56 am
      I would be interested to see the fruits of your labour on this
    • Oct 11 2013 | 11: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.
    • Oct 11 2013 | 12:22 pm
      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
    • Oct 11 2013 | 2:47 pm
      @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.
    • Oct 11 2013 | 4:59 pm
      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.)
    • Oct 11 2013 | 6:35 pm
      ah, very nice, that's simple enough.
      What does the "krt" mean in the diagram, by the way?
    • Oct 11 2013 | 7: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. :)
    • Oct 11 2013 | 7:12 pm
      Yeah, the prime part only matters in relationship to each other..maybe better expressed as "minimize the GCD"
    • Oct 11 2013 | 7:20 pm
      be careful to substract one time the vectorsize from the third delay (or from the first)
    • Oct 11 2013 | 8:58 pm
      can you elaborate, Roman? I have no clue what you're talking about :)
    • Oct 11 2013 | 9: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:
    • Oct 11 2013 | 10:46 pm
      what i mean is ... feeding back introduces a change to the desired delay times ... not sure if it applies. :)
    • Oct 12 2013 | 7: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 http://www.spinsemi.com/knowledge_base/effects.html#Delay_effects.
    • Oct 13 2013 | 7:05 pm
      Is KRT a gain stage?
    • Oct 13 2013 | 10:28 pm
      krt. krt. krrrrrt.
      krt bumm.
    • Oct 13 2013 | 11: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.
    • Oct 14 2013 | 12:17 am
      reverb time is usually controlled by the feedbacks amplification ...