Hi! I’m proud to introduce my first ER-301 V6 package: FilterDelays.
It currently contains 5 bespoke units:
FilterDelay: a clocked delay with tone control in the feedback path and, in the stereo version, a randomized spread control. It takes about 9-10% CPU in the stereo version.
TunedFilterDelay: a delay with tone control in the feedback path and a V/Oct tuned delay time. Note that the maximum frequency is about 375Hz, because of the way the delay feedback is patched. It takes about 9-10% CPU in the stereo version.
Here’s a demo:
FDN: a Feedback Delay Network, inspired by a paper by Tom Erbe - UC San Diego: REVERB TOPOLOGIES AND DESIGN. With smallish delay times it sounds like a simple gritty reverb with tone control. But the room size (i.e. delay time) can be made unrealistically big, so it can sound like a delay that eventually smears out into reverb. It takes about 20% CPU in the stereo version.
Here’s a demo:
SFDN: a simpler version of FDN, without modulation, so cheaper delay lines can be used. It uses only 11%-12% CPU.
Manual Grain Delay: the unholy child of Filter Delay and Manual Grains. It is a delay line with tone control in the feedback loop. But instead of just playing the delayed signal, you trigger grains, with all the usual controls you expect from grains: pitch, duration and squash (pan is coming in some next release). You can also freeze the delay loop and play with grains in the frozen buffer. It’s a bit like part of Mutable Instruments Clouds, but without the auto-triggering and the reverb.
The stereo version uses 10%-40% CPU, depending on how many grains are running concurrently.
Many many thanks to @tomf: without his GitHub repo, I would not have been able to create my first C++ -layer unit!
Yes, that’s the same paper. The difference with my unit is that the room size can go MUCH bigger. On the other hand, the Erbverb has much more modulation possibilities and other refinements. I guess most of its functionality could be replicated in ER-301, but there is of course always the matter of CPU usage. It’s currently at about 20% CPU, and I don’t really want to go much higher than that. The current version is made with lua patching. I guess some more cycles can be gained when coding it in C++, but that’s a bit beyond me for the moment…
0.6 has been posing no problems for me so far. I was a bit hesitant to switch at first, but I’m happy I did. The package system is so much better than before and the emulator is just super when coding units!
Just to note, it wasn’t really my intention to copy the ErbVerb. I also had an ErbVerb (damn me, I sold it…) but always wanted to be able to make the delay lines much bigger. So this unit is based on the same principles, with much bigger delay lines (up to 2 seconds, but I’m thinking about increasing it even more). But other than that, it’s really a different beast. ErbVerb is excellent for patching all sorts of weirdness.
wow! the FDN is awesome!
question: is the dry input always on? if so, can we have a dry\wet crossfader?
i usually use my spatialization effects (delay and verbs) on an aux send from my mixer, so i’d like to have the wet part only of the FDN.
Hi! I’m glad you like it! The dry is indeed always on, currently. I typically use the input level control to periodically feed some sound into the FDN, like to get snippets of sound ‘remembered’ by it. But I can indeed see the more typical reverb effect use case where a dry/wet fader would be super useful. I’ll add it in the next version. I’ll keep the input level fader too though.
Thanks for the suggestion!
Is a great unit. can I ask you some details? I assume you use it on two stereo linked channels.
are you using only one INPUT? so the signal that the delay will process only enters input 1 in mono or are there two different sources?
The FDN essentially consists of 4 delay lines, each feeding into all the others. The left and right input are injected into 2 of those delay lines and the left and right output are taken from 2 delay lines too. So it is a true stereo effect. Of course, since all delays feed into each other, left and right input quickly get mixed up. I hope this answers your question. The paper I linked above contains all the details on how this works exactly.