Reverse Delay - first module prototype

I’m not sure how many people would be interested in this, but I was looking for a reverse delay and couldn’t find one, so I made my first module. But I’m rather inexperienced at releasing software, so I’d be curious if it works for anybody or if it’s something that people would like to see improved upon.

This one basically satisfies what I was looking for, which is a continuous delay loop played in reverse with a crossfade when the read/write heads pass each other.

There’s no dry passthrough, everything is wet, and there’s no real niceness on the controls to prevent clicks when adjusting buffer sizes or head locations, but if people find it useful, I’ll put some more time into it and release it properly. I figured there would be a learning curve to releasing a prototype like this, so apologies ahead of time if I’ve missed anything obvious.


Finally sitting down to play with it properly, it’s nice to disable the internal feedback and add a little character with some of the ChowDSP tape modeling modules:


Thank you Dan for making this module. I was the one that started the thread, so I really appreciate what you have done.

Going to give it a good work out today.

1 Like

Hi Dan,

this is a good start :+1:

there are some clicks and noises audible when using it, will you try to remove these?

would it be possible to add a syncable delay timing?

1 Like

If you can duplicate them, let me know, I’d be glad to duplicate them here and solve them. I was using it for several hours yesterday and didn’t hear any clicks that weren’t part of the audio I was inputting to it.

I was using sine tones, bell tones, and voice.

I want to make sure to get the underlying sounds right before loading it up with extra features.

Stephan, if you could me know what sample rate you’re using, I’m planning on optimizing for a wider range of sample rates next. That could be the problem.

normally I use 48kHz samplerate.
I try to send you a patch asap,
I’m at work now

1 Like

here is the patch:

2023_02_27_Reverse-Delay_bug_02.vcv (22.3 KB)

the crackles come mostly from the mix output

1 Like

Hi Dan,

Just got round to testing this, and it works great with guitar! I’m on Windows and haven’t found any issues yet. Would be nice if you could modulate parameters while it’s playing back, not sure if that’s possible. Using 2 or 3 modules with different delay times sounds awesome, it repeats bits of what you just played nice and smoothly, but backwards, which is exactly what I wanted. Nice job so far!



1 Like

Perfect, that’s great to hear!! I’m thinking about what changes I want to make, I’m letting them kick around my head a bit, but if you find yourself wishing for certain things while using it, let me know.


I added a clock input this weekend, I’ve just been testing it out, I think it works pretty well, I’ve never had a clockable reverse delay before. It works better with some sound sources rather than others, but it’s actually quite a nice texture. And the location knob seems a bit more useful when it’s clocked.

The only thing is, I haven’t added any really smart filtering to the clock input, so if the clock is wobbly, you’ll get clicks as the buffer length changes.

I can fix that in the future, but for now, if you want to ‘latch’ in a buffer setting, just remove the clock input and don’t touch the length knob and it will stay fixed.

@SuperMuppet and @ady34 thanks for the feedback! and ady34, I listened to the soundcloud post, very cool. It feels good to have a module to contribute to this community finally!

I’m feeling gradually a bit more confident coding in the vcv environment, so hopefully that will mean gradually nicer features and hopefully a prettier faceplate design at some point.

v2.0.0.4 - added the clock and fixed an issue with the reverse location not working properly.

Link is the same as above, I’ve made it the general location for all releases at the moment and added a release notes file:


Oh, also, FYI, the length knob does nothing while a cable is connected to the clock input.

I think probably adding a relative selector like chronoblob has would be handy.

But I’ll want to add filtering to the clock input. I might try to pull from the Marbles clock input, as that’s the least finicky one that I’ve ever encountered, but if anybody else has clock input filtering suggestions, let me know.


Thanks for the updates, I’ll give it another good workout. Might try… not sure yet! I’ll post audio on Soundcloud. Multe Gracie

1 Like

just found this thread now. trying out the module, and i really like it! very interesting and different from any other delay i’ve played with in Rack. great work! look forward to seeing any further work from you, if you decide to make more.

1 Like

Would love to hear your guitar through this module patch, is there audio or even the patch available? Life treating you kind?

1 Like

Yep all good @ady34. As always, I went off on a total tangent and went a bit over the top, so the patch that started with a few reverse delays somehow ended up with 16 Chronoblobs using the send/return loop, but with feedback loops going into a merge and then through a polyphonic flanger and a filter. After that, it wasn’t really demonstrating Dan’s module because the reverse delays were feeding into a load of madness, so I haven’t posted it anywhere. :joy: Incidentally, with polyphony I don’t need to create these crazy patches with tons of modules, but sadly Chronoblob isn’t poly yet and I couldn’t find a poly delay with send/return loops. There’s an idea for you Dan!

1 Like

Thanks @alefnull,I really appreciate that!

1 Like

For delay send/return loops try the Venom Modules Recurse (Comes in mono and stereo versions). Does that do what you need? It’s polyphonic to boot…

1 Like

I started to dig into the Marbles clock input to figure out why it’s so much better than all the others, and I found it, holy crap, this is lovely.

I’d been mentally designing a better clock input for the past couple of days, just in my own head, and this is like leapfrogging a bunch of problems I was wrestling with, mainly that I could imagine several approaches and what if one was better than another for a given situation? Check out this explanatory comment from Emilie Gillet’s ramp_extractor.h:

That’s beautiful. That solves so many problems. Basically I was trying to figure out how to deal with a clock that is wrong sometimes, and wanting to figure out which of the clock pulses were the ‘right one’, this is exactly the way. Use different ways of guessing to predict the next edge, and stick with which ever predictor is right more often than any of the others, and I think that will give a much steadier clock pulse that can also be changed relatively quickly, but also won’t slew around all the time if the clock generator pulse is a little unreliable.

It’s just so brilliant and beautiful, and such a subtle paradigm shift.