The Can-Abyss Delay is my modern interpretation of the 1960s electrostatic “oil can” delays (Ray Lubow’s Tel-Ray, sold as Ad-N-Echo and Morley) for MOD Duo, Duo X and Dwarf. Faithful research and physics, with modern mods and enhancements.
Built for the dark hours
This isn’t a slapback for the morning commute. It’s a can of slow-dripping echoes for late nights, sound design and jams that brood more than they resolve. Even the knobs sink. They start at eleven o’clock, drop through six and climb back out at one. Tone hangs straight down when it’s flat. It’s confusing, yes! But it forces you to focus on tone.
Why it sounds like nothing else
There’s no tape and no erase head. A spinning disc in a can of oil holds the signal as charge, and the disc never fully forgets:
Echoes smear into a half-reverb wash. Leftover charge comes round every revolution, fainter and darker each pass.
The motor sets the time. Turn Time and the pitch bends, like tape. Freeze the disc with Hold and it still varispeeds.
The warble is mechanical. Disc runout, belt drift, motor flutter and disc wear, locked to disc speed.
Clean by design. The old units hissed and hummed; this one keeps the movement and drops the noise.
Long delays get darker by themselves, because the disc surface moves slower past the wiper.
My first original creation, so felt I could really flex the UI to be more ambitious and adventurous. Always loved the Line6 Oil Can model on my Echo Pro but it was too much of a one trick pony. The Can Abyss is probably the most tweakable oil can delay in existence! I’ll have a jam tonight, see if i can create some presets and samples.
Because of how the MOD builder fetches the code. The package .mk points at the repo with $(call github,owner,repo,commit), which downloads GitHub’s archive tarball for that commit. GitHub’s archives don’t include submodule contents, so with DPF as a submodule the builder gets an empty dpf/ folder and the build fails. Vendoring guarantees the builder sees exactly the code I tested.
Side benefits: the repo builds from a plain download with no extra steps, and DPF is pinned to one exact commit (61d38eb6…). It only vendors the DSP-only part (about 2.7 MB), not the GUI libraries.
You’re right about the cost. Updating DPF is a manual step, and the update shows up as a big diff instead of a one-line submodule bump. That is softened with a script (tools/vendor_dpf.sh): change the pinned commit, re-run it, then run the full test gate before committing.
Ik woon al weer 20 jaar in Nieuw Zeeland, maar kom uit Rotterdam.
A bone dry test recording, just a muted A minor going through progressively more Wobble, Wear, Sag, etc. From about 2 minutes onwards it’ll start to get more feverish. From 4 minutes onwards is playing with the oscillations. I did have “safety” on to keep levels under control and turned the mix down a bit too much, but it’ll give you an idea.
@dreamer Yes, that’s a fair observation. I am user centered designer and I do rely largely on Claude Code to do the heavy lifting. That does mean I make decisions from a “good UX” perspective.
So I respect if this would not be good practice in terms of development, and that DPF wouldn’t recommend it is also not really surprising. It’s really to provide a better User Experience while the plug-in is in an early stage. To me what matters most is to have inspiring sounds and a surface that invites exploration.
It’s pretty much getting to a point where digital is more analog than analog. I absolutely love playing with the disc size in real time, something physically impossible but sonically useful!
I did some sleuthing and I think the solution was already there. mod-plugin-builder already has a submodule hook (MOD_PLUGIN_BUILDER_DOWNLOAD_WITH_SUBMODULES), and your wstd-dlay actually already uses it. I’m testing whether the online builder supports it too. If it does, the playbook will switch to DPF as a submodule and drop the vendoring. As well as all builds I have on Github.
Edit: All tested and deployed! No more vendoring on the Playbook and all NHE plugins.