Building samplers and sampling-based modules with delays

The things @stschoen wrote in the reverse delay thread made me see delay nodes more as buffers (because thats what they actually are).
With this in mind I had some ideas that lead to the biggest mindblow I had since buying Audulus :smile:.
I found a way to build samplers and other sampling-based modules with delays.

Here is a patch that explains the tricks you can use to do this:
Delay Samplers.audulus (334.0 KB)

Here are some prototypes I‘ve built using these tricks:
prototypes.audulus (1.8 MB)

:warning: Since this trick uses delay nodes as buffers, everything you ‘record‘ into such a ‘sampler‘ will be lost as soon as you close the patch.

Of course feel free to use these tricks and modules for your own stuff :smiley:.


Since this trick uses delay nodes as buffers, everything you ‘record‘ into such a ‘sampler‘ will be lost in time, like tears in rain.:slightly_smiling_face:


Nice! I agree the delay node is underutilized as a sampler/slicer. Perhaps making some looper modules will also reduce the urge to buy an MC-707.

I had to unload a year’s worth of samples from the Digitakt in order to continue using it. It was like you said, all the projects that go with those samples are now ghost songs waiting for sounds that will never come.

Also what is the limit to the length of the delay buffer? I vaguely recall it is a nice round number of samples but the number of zeros is escaping me.

1 Like

The limit is 1 000 000 samples (nice and round :P)

Verry poetic :smiley:


one MILLION samples?


and there’s no option to backup ALL data - samples, songs, sequences - everything?

And that gives us 20 seconds-ish. More than enough for some sweet time-lag sound on sound loops) Possibly with a bit a warble and tape-like degradation.

1 Like

[Edit — slimmer version with some functionality added]
I’ve learned a few things dealing with delay nodes:

  1. (Pretty obvious) Without a stable delay period, a sample will degrade over time, smearing out and generating a noisy burst at the endpoint. Slow adopter as I am, it only just the other day occured to me to generate my clock in Audulus and trigger my drum machine with a DAC output. My drum machine’s sync out had a lot of jitter, especially at the turnaround.
  2. (Less obvious) when I made my own feedback around the delay node, I found that it messed up the timing. My loop would fall out of sync with the external sampled signal. On a gross level the two methods seemed equivalent, but with the feedback built around the node, it was as if a tiny delay was added which padded out the delay value a bit, building over time as the loop signal was fed back in. I noticed this effect when sampling the drum machine. The machine and the looping copy would begin slipping. Setting the node’s feedback knob to full clockwise resulted in perfect time alignment.

Naturally, I built a behemoth with delays: [somewhat slimmed v7]
Delay Looper 7.audulus (1.5 MB)

I switched to a BPM entry gadget (one I made which latches any changes in tempo that you dial in, applying it to the output with a button press.) The clock from the BPM entry is output to DAC channel 4 to trigger my drum machine (ADC channel 4 takes the drum machine audio.). The frequency output from the BPM entry is used as the timing source for the loopers.

I made the delay looper modules using the state machine approach, which makes them hogs but allowed easier experimentation. I’m going to try the simple logic version again soon. This one occasionally oscillates between states, but not enough to bug me at the moment. The hog aspect makes the example patch, which has four of these loopers, more a desktop project than an iPad-based one.

Delay Looper (135.0 KB)


  • Per—the input period, in seconds
  • Enable—a high is needed for the looper to respond.
  • Samp^—a trigger here starts capture of whatever follows, up until end of loop period. See “NoTails” input, below, for how long decay or run-on content is handled.
  • Erase^—a trigger erases the loop. You can add audio immediately after hitting erase. Sampled audio will stream in if the module is enabled. MIDI keyboard hits will register and be recorded,
  • Mode—The looper modules have two modes—pile-on and single. A high at the mode input switches to single mode.
  • NoTails—In single mode with this input low, the looper will wait for five samples below a minimum loudness threshold before cutting input. With the input high, capture cuts at the end of one sampling period. Keeping tails is appropriate for gated sound sources that you control, like synths, where’re you might have set a decay longer than the loop time. The excess audio loops back around. With input high, the looper cuts off at the end, allowing sampling of continuous audio sources like drum machines.


  • Clock mult/div—adjusts the input period (at ‘per’ input) For various loop lengths.
  • Fb—the feedback . Set to 100% (aka 1), it’ll loop on forever.

Here’s a clip—bad sound and all:


Did you try using a unit delay in your external loop? By default A3 inserts a one frame delay in any feedback loop.

1 Like

You know what? I HAD put the delay node in the loop then took it out at some point. That is probably the source of the timing problem. Hard to say what A3 has to do to cover that situation inside the node.

1 Like

AFAIK the internal loop uses a single sample delay.

1 Like

BTW killer patch! :cowboy_hat_face:

1 Like

Thanks! How about the 150% of processor time from the iPad screen shot!


Didn’t notice that. Definitely a hog lol.


I had fun sampling the drum machine with two loopers, one running over three clock periods and one over five. The drum machine is running some 16-step sequence, but only the two loopers are heard because I turned the direct drum machine channel down.


Yep! It needs to go to Weight Watchers!


Typical for me, I tinkered a bit!

Delay Looper 9.audulus (1.6 MB)

I ended up leaving the loopers in the state machine implementation. That didn’t cost as much (in processor load) as I thought and the features it allowed made that cost worth it for me.

With the delays settled I started looking at randomization of some of the high-Q filter nodes to give it all some variability. I added three of my random knob modules to modulate the center freq of the filters.

There are still four loopers, each with a midi-note-tracking, peaky, high-Q filter. Each filter has its nominal frequency, relative to a stored midi note value, set by a knob.

(The random knob modules issue random values nominally distributed about a mean ranging from 0 to 1. Variability conforms to the normal distribution, with the range of variability falling within approximately +/- three standard deviations. Final distribution is either constrained to [0-1] or is unbounded, depending on the value applied at the [0-1] input. You set mean with the left knob and variability with the right knob.)

Looper one and two are set to take input from the synth (the combo res-drum mod and SMOL synth). The third and fourth loopers are controlled together and enabled by the Bb key from the White Key Module (or the corresponding button when in chromatic mode), with loopers set for 3 and 5 clock cycles, respectively, to give a polyrhythm effect.

The first looper’s nominal filter frequency is set manually. The others are set by the random knob modules. For the drum samplers, the main clock sets the pace of the randomization.

Here’s a demo.

For this demo I wanted to try for a “caffeinated forest” effect, using chromatic bends through the res-drum side of the combo synth (). A separate, faster, clock runs the 2nd loop’s random generator to add to the bird frenzy I was after.

Another module I added was to “taps the breaks” on recursive loops whose envelope grows above some set value. The envelope is filtered using a running averager and the true/false answer is fed back to that looper’s feedback knob. This allows you to add to a sound bed without the bed’s amplitude growing without bound. When the envelope falls below the setpoint, the feedback is reset to 1. Kind of an AGC feature.

I’ll maybe break out some modules into proper Module posts later on.

PS many thanks [again!] to stschoen for the fantastic Normal Distribution module, in which he did the hard work in bringing the Box-Muller Algorithm to Audulus!

1 Like

Yes that would be very cool. I suspect it’s all going to carry forward into Audulus 4 anyway, so the designs will evolve but also stand in as useful in their current form.