Resonator Delay

 

One of the great sounds that come from analog/analog-style delays is when the feedback is set very high, and the signal begins to run away to self-oscillation. There are many guitar pedals that even have a switch or function that when held, ramp up the feedback to its maximum in order to create moments of this. The only problem with this effect is that it inevitably saturates, and what you’re left with is the self-oscillation. This sound, while useful in its own right, usually loses its relation to the input signal and instead becomes a characteristic of the delay effect itself.

This is where the effect I’ve called the “resonator delay” comes in. As you can hear in the clips above using the lovely max example sounds, the idea is to have that build-up to self-oscillation sound happen whenever you want—triggered by a “bang” sent into the patch. This bang clears the delay’s buffer and allows another build-up of feedback in what I refer to as a “mute and clear” event. Below is the main patch with its controls.

resonator-delay-main-patch.png

So as the image shows, there are seven inlets and they are laid out as follows:

  1. Where the signal to be processed goes in.
  2. Where a bang is sent, triggering a “mute and clear” of the delay buffer.
  3. The probability out of 1 that you’d like the bang to trigger the “mute and clear”.
  4. The probability out of 1 that a new delay time is chosen.
  5. The minimum possible delay time in milliseconds.
  6. The maximum possible delay time in milliseconds.
  7. The time in milliseconds for the delay time to ramp to a newly selected delay time.

Now let’s take a look inside at the various subpatchers within.

resonator-delay-insides.png

Delay Taps

resonator-delay-delay-taps

Inside the delay taps subpatch, you’ll find a pair of [tapin]s (left and right) with a buffer size of one second. Both of these have a feedback loop set to 97% regeneration and are ran through a [tanh~]. The [tanh~] is used to create a smoother overdrive sound, as without it the volume would get out of control and clip the output of the DAC.

Trigger

resonator-delay-trigger.png

When a bang is sent into the patch, a random number is checked to see if it is below the probability set by the trigger control. If it is, a bang is sent out to the “mute-and-clear” and “random-delay-times” subpatchers. The reason I use a probability here is that typically I’m using the detection of note (or percussion) attacks to trigger the mute and clear event. In the example shown of the patch exterior and controls, you can see that the [bonk~] external is being used to detect onsets. Using a probability to determine whether a mute and clear event actually takes place allows for more control of the effect itself. It can be set to mute and clear on every attack or dialed back so that it only happens on some attacks.

Mute and Clear

resonator-delay-mute-and-clear

Once the bang is sent out of the trigger subpatch it enters two places, one of which is the mute and clear subpatch. This is the primary function of the patch. When triggered, the input and output signal of the effect is muted, the delay buffers are cleared, and the volume is brought back up. The other destination for the bang is the random-delay-times subpatch.

Random Delay Times

resonator-delay-new-delay-time.png

In this subpatch as well, the bang triggers a probability check. This one determines whether or not a new delay time is chosen from the user selected range. Finally, the new delay time is transitioned to based on the ramp time. This whole process happens simultaneously for both the left and right delays.

Some future directions for this effect might be adding other processing units within the feedback loop, modulating the delay times continuously (maybe even as some sort of function) instead of intermittently, or perhaps using something other than note attacks as the trigger for a mute and clear event.