VCV Rack - Galactic Reverb has zipper noise on the Bigness knob

I'm really enjoying using Galactic Reverb in VCV Rack! The only unpleasant thing is that when I manually turn the Bigness knob, I hear zipper noise. I'm guessing the bigness is getting stepped with the display frame rate?

Yes that’s correct

modulations are applied at block size but the Param ui widgets are direct

I guess there’s a smoothed api I should be using or some such right? Do you happen to know latest greatest?

I think parameter smoothing is now the default in VCV Rack, only you are supposed to poll the parameter at audio rate in your process method.

And it looks like you are already doing that in src-rack/Module.cpp. Hmm.

Yeah I wonder if I did something to turn off soothing. I poll every time I need a block indeed

airwin2rack/src-rack/Module.cpp

Line 154 in 33650be

pq->smoothEnabled = true;

Oh wonder why I did thst.

Wanna try it with thst set to true and see if it solves it? I can’t imagine why I would have done that now I look at the code

I'm really enjoying using Galactic Reverb in VCV Rack! The only unpleasant thing is that when I manually turn the Bigness knob, I hear zipper noise. I'm guessing the bigness is getting stepped with the display frame rate?

Um. I'm Chris from Airwindows. You do understand that Bigness is changing the size of all the delay buffers in the reverb at once? There are plenty of effects like that, where they are based on a bunch of raw delays and allpasses. Paul can't smooth THAT, nor is it meant to be. He did fine. I would ask that this be closed on the grounds that it is working as intended: none of these reverbs are at all designed to smoothly automate 'delay buffer size' controls, they are designed like the way some ZVex stompbox knobs are designed: for those, there can be a crackle while adjusting because they bias transistors through a voltage flow in the potentiometer to allow for a simplified circuit. With Galactic and similar reverbs, they allow for a simplified delay path through adjusting the maximum delay time on a fixed buffer, rather than changing the rate through the buffer and forcing the sound to either interpolate or generate huge amounts of aliasing as it steps by non-integer amounts across the buffer.

Allow the sound to become silence before changing all the delay buffers at once and then there won't be extraneous noises… unless you're expanding the buffer, and you had previously loaded them with live sound before shortening it. (I am certain I've got some users in London doing that on purpose, for effect)

Crackling noises OK, don't fix (as it says on the Live At Leeds record…)

Chris - there's two issues here

are your fx stable under parameter change? Maybe yes maybe no. that's what you shared above and that's not getting fixed
When you twist a knob does it update your effect at GUI refresh rate or audio refresh rate. If you aren't stable you will still crackle but for things like mix if I did the GUI refresh rate, you will get zippers.
I did the GUI refresh rate which is the line above

So if don sets that line back to true the galactic will still be rocky when you change bigness since you aren't incremental in parameter. But the mix won't zipper anymore. Just like it doesn't if you map it with CV.

If we can confirm that, we can remove the line and close this.

Oh also, Chris, if you haven't tried Don's VCV rack modules, they are some of my favorite! Definitely worth it :)

Oh darnit that line says smoothEnable = true doesn't it. I have smoothing on.

Then chris you are exactly right. This is as good as it gets. Sorry!

Let me confirm that when it's not a matter of rewriting the actual effect to be not the effect I have under that name, I've no objection to Consolidated interacting with the controls differently. Remember, my effects don't have their own GUI refresh rate, so if this exists in Consolidated and is different from buffer size, that's on your end and you're welcome to do whatever to address it.

Yeah I already do that. Basically I have smoothing on. And also you can choose a param update block size of your choosing down to 4.

Still won't make galactic stable under changing the bigness though.

Understand that part of the design constraints for my stuff includes the times when I'm not calculating smoothing on the control inputs. There are specific plugins, including one coming out soon, that extensively smooth things by lerping the controls or code inputs from start to end of sample buffer (always linearly, but there have been exceptions before). There are also ones, including one coming out soon, that specifically avoid that behavior in pursuit of raw CPU efficiency over something that's maybe a little more cpu greedy (though, by comparison with modern plugins…)

I'll continue to pay attention, and will continue to not be the only voice on the project, and we'll do what we can :)

i basically assume 'at the top of i block i set your params then you do best you can'

the thing i thought was 'i was not smoothing the gui knob' but I am.

And 'block size' is a module parameter in the rack module. In the clap we use the sample accurate automation to divide the block. in the vst3 and lv2 and au we just use the daw block size.

Thanks guys! I was just reporting this with an intention of being helpful. I thought it might be an unwanted artifact added by the port to VCV Rack. Now I know that's just the way it's supposed to be. Generally I don't need cavity size to vary while I'm performing, so setting Bigness before a performance and leaving it there is just fine.

I have to say @airwindows, your work is amazing. Recently I have become obsessed with creating my own reverb algorithm. It turns out it's WAY more complicated than I thought. When I saw someone using Airwindows Galactic in their patch, I had to try it out. I was blown away. This is exactly the kind of ethereal synth pad juice I have been looking for!

Your GalacticProc.cpp is compact, clean, and easy enough to follow that I'm tempted to adapt and develop a variant reverb based on it. I'm pondering creating an integrated synth pad module for VCV Rack, and this reverb would be a perfect internal component for it. I would of course give you name/link credit if I do that.

Did you base Galactic on some other algorithm, or is it your own original creation? I would love to read any published papers about it, if any exist. It's a wonderful complement to Valley Plateau. As an example, here is a patch I created that uses both reverbs, each playing a different role ... I really enjoyed this...

"I'm tempted to adapt and develop a variant reverb based on it." Go for it! Nothing would please me better. Vary things to see what they do! I can give some hints.

These are all based on feedfoward algorithms with global feedback and are otherwise not special. Feedforward means, by the time you get to the end everything's had every possible combination of combined delay times, so there's lots of echo density. As of late I've been experimenting with replacing some of those delays (comb filters) with allpass filters (as seen in MV and MV2) because using only comb filters like Galactic is limiting. There are no published papers, I don't write papers. I got the idea from Casey from Bricasti publically talking about feedforward reverbs and Householder matrixes.

Try things! You might make something really neat to listen to :)

And Don - think every pad I’ve written in surge vst for the last couple of years has a bit of galactic in it. It is great for that use case

As of late I've been experimenting with replacing some of those delays (comb filters) with allpass filters (as seen in MV and MV2) because using only comb filters like Galactic is limiting.

OK, this is already very educational for me. I have recently started implementing my own allpass filters, as an attempt to ladder my way up toward something like Valley Plateau, which uses a plate reverb algorithm by Jon Dattorro.

Here is my class template AllpassFilter, which supports sinc-interpolation to allow non-integer sample times in the past, for precise tuning.

I have an experimental VCV Rack module that implements the allpass filter by itself, with knobs to control the parameters. I had the idea that if I could create enough modules that act like the building blocks in Dattorro's plate reverb, then I could build a wide variety of candidate reverb algorithms without any additional coding. Once you cable up something you like, I can almost imagine a code generator translating the prototype patch vcv file into C++ code.

What I love about your comb filters approach is yes, comb filters distort frequency response, but with enough of them, it seems to smooth out into a pleasing effect of its own. I did not suspect that! And adjusting the wavelength is a natural way of tuning them, which makes them musically promising.

I got the idea from Casey from Bricasti publically talking about feedforward reverbs and Householder matrixes.

Thank you, more good keywords to use in searches.

And Don - think every pad I’ve written in surge vst for the last couple of years has a bit of galactic in it. It is great for that use case

That's great to hear! OK, I am excited to give this a try for real...