ChowDSP Development Thread

Hi VCV Folks,

I’ve got a few modules that I think are ready for a small-ish release. I wanted to ask about the typical release workflow: is it recommended to ask for beta testers, and then release to the VCV Library, or release to the VCV Library first, and then ask people to test?

That being said, if anyone wants to test, I’ve got a tape distortion, a couple phasing effects, and a reverb, available here:

Thanks, Jatin


Amazing! I read about your AnalogTapeModel a few weeks ago and thought „Wow, this would be nice to have as single modules in Rack…“


Wow, that was fast :slight_smile: Congrats, I’ll be giving it a try for sure!


I think it’s best to ask for beta testers before submitting to the VCV Library. Each time you submit to the Library, it will go through their review process prior to being available to users. The more complete your plugin is before submitting, the less time you and they will spend on reviewing/waiting.


This makes sense. Thank you!

1 Like

I just found your vst-plugins some days ago,

and I tried them in Host,

I would like to test your vcv modules too, but I can’t compile them myself, so I would need some Windows binaries.

I’m still trying to figure out getting my windows builds to work through AzureCI, so in the meantime, I’ve manually uploaded a Windows zip:

1 Like


First test ok on Mac, sound good, thanks to share.

if needed Mac release

Fantastic news. I’ve been toying with your VSTs for a while now and the Tape Distortion is among the finest I’ve heard ITB.

The modules compile and run without a problem here on Win10.

ooh these look interesting!!!

The modules are pretty nice, but I might have found a bug,

the Tape sometimes gets pretty distorted when it seems to be overloaded. and the distortion is still there even when I stop the sequencer and don’t pass any sound through “Tape” and after a few seconds I turn the sequencer and clock on again, the distorted sound is still there. I know that I have build a very unusual routig with feedback, but I just would let you know. And I think this is what beta testing is for :wink:

here is a patch where I got the “overload distortion” 2020_07_30_Chow_Tape_Overload_001.vcv (40.4 KB)

Thanks all!

@rsmus7, seems like a stability issue… The magnetic hysteresis model that I use can be a little bit finnicky when it gets overloaded, especially without internal oversampling (which I’m still trying to figure out if I can do within the Rack API). In my plugin version I only offer +6dB of input gain within the plugin, and try to instruct the user to keep the overall levels at or below unity going into the plugin, and this seems to work reasonably well. Obviously, in Rack it’s much more difficult to keep track of gain staging from module to module.

There are solution’s but there’s always tradeoffs: I can use a smaller alpha coefficient for the alpha transform, but this will add some high-frequency damping. I can also switch from using a 2nd-order Runge Kutta solver to a Newton-Raphson solver, which is more computationally expensive. In my opinion, these tradeoffs are worth it for a more robust module, so users don’t have to worry about things like this, and can go about their patching fearlessy. Anyway, I’ll get these implemented soon…

By the way, very cool patch! Not sure if that seems run-of-the-mill to you more experienced folks, but as a relative newbie, I’m amazed at what you modular wizards come up with :slight_smile:.

Anyway, sorry to get a little bit technical. I’ll actually be off-the-grid the next few days, but I’ll be sure to check back at this thread when I return.

Thanks, Jatin


Look at that, you’re already in the library, congrats Jatin!


thank you Jatin for this explanation :+1:

1 Like

Hi all,

Still a few more things I’d like to add before the next release, but I wanted to let you all know about some changes and see if anyone wants to try the latest builds:

  • I’ve added 4x internal oversampling to the CHOW Tape module. This helps to avoid aliasing artifacts, and improves the module stability. I could go to higher oversampling factors, but I think 4x is a good compromise to supress aliasing without taking up too much CPU.

  • In CHOW FDN, I’ve switched my delay lines from using sinc interpolation to 3rd-order Lagrange interpolation. This greatly reduces the CPU footprint.

  • I’ve added a new module, a recurrent neural network with 4 inputs. I’ve had some fun using this as a distortion-type effect, but it can come up with some kind of strange and interesting results. Eventually, I’m hoping to add some pre-trained networks to this module.

For developers: I’ve made a generalised oversampling class to use for the tape module. It uses an arbitrary order Butterworth filter for anti-aliasing and anti-imaging. It should be pretty easy to set up for use in any module, as well as extend to use different filters if you prefer. Check it out here!


i think it should include Mode.hpp (with capital M) to compile properly on system with case sensitive filenames …

best wishes - hexdump

1 Like

I keep linux running in a VM just to find this one problem (case sensitive include file names).

Hey all,

Just finished some updates in preparation for a new release. If anyone wants to try out the latest builds, those can be downloaded here. Updates include:

  • New virtual analog distortion module (“ChowDer”). I had some fun modelling a couple old circuits using some Wave Digital Filter code I wrote a few months back. If any other developers want to use my WDF code for their own circuit models, I’m more than happy to help out (plus it’s all open source :slight_smile:).

  • Updated GUI designs for all modules, courtesy of my friend Margus (I don’t think he’s on the forum yet).

  • Small performance improvements for all modules, especially the Tape module.

  • For devs: The performance improvements were aided by a benchmarking app that I made, inspired by @Squinky.Labs. The approach is a little bit tricky to get set up, but it’s nice in that it benchmarks the modules directly rather the internal DSP functions, so it should be pretty generalisable to anyone else’s modules as well. For more information, see here.

Thanks, Jatin


Oh, that’s cool. It sounds like you linked in rack code so that you can benchmark your plugin binary directly? That’s nice. Always wanted to do that… never did.

1 Like