Superfluity

Coding

Nebulizer builds from the same set of tools as its counterparts Frobulator and Muckraker: coded in C, Objective-C and Swift using Michael Tyson’s Amazing Audio Engine, the Audiobus SDK, Nic Grant’s MidiBus library and Apple’s Accelerate framework. These things are discussed in a little more detail on the Frobulator tech page.

That one was written first. Obviously. And it would be otiose to go over it all again. Just click the damn link if you’re interested.

Functionality

Nebulizer’s basic processing is embarassingly simple: like all delays, it buffers incoming audio and then adds it to audio that comes along later — like playing back a tape. There is also feedback: some of the delayed audio may be layered back into the buffer when it gets replayed, creating multiple, decaying repeats. That’s pretty much all that’s going on.

One thing that makes Nebulizer a little different from some (though by no means all) delays is that the buffered audio isn't played back as is, but is squashed or stretched a bit. The delay drifts around the base time set by the time knob, modulated by low frequency oscillators that are in turn modulated by the other controls.

(Some such variability is inevitable in many analogue delay systems — the stretching of a tape, for example. Nebulizer doesn’t attempt to model or reproduce the characteristics of such systems — that would be too much like hard work. We are — let’s be honest here — lazy bastards, and very much prefer cheap hackery and sleight of hand to true physical modelling. Still, we have to admit that some of the inspiration for this app comes from that kind of analogue behaviour.)

To manage the drifting, the delayed audio is broken into small (32 sample) chunks and interpolated — sometimes even reversed — to fit into the required time. This interpolation is performed using the Accelerate lookup table function vDSP_tabi, which is also used for an optional boosting & clipping transform enabled by bleed.

As a result of all this, at any given moment the effective delay time is almost never exactly that set by the knob, it’s a bit faster or slower — potentially quite a lot faster or slower, if both time and evasion are set high. How rapidly the delay time changes is the main thing controlled by vergence, which acts as a kind of filter on the variability.

In addition, there are several actual (second order infinite impulse response, aka biquad) filters in the signal path. There is a low-pass before the delay, either a low or bandpass after (depending on the setting of the itch button) and a notch filter that attempts to knock down some of the artefacts that result from the fixed 32 sample processing size. As with Frobulator and Muckraker, these filtersn are implemented via the Accelerate vDSP_deq22 function, based on Robert Bristow-Johnson's Audio EQ Cookbook.

The pre and post filters are controlled by the regret and loss knobs respectively. (Among other things. In order to keep the interface relatively uncluttered, the controls have multiple duties.) Just to confuse matters, the loss contribution is inverted for this parameter — that is, a high loss equates to a low cutoff. This is simply a semantic choice: increasing loss clearly sounds like it should mean letting less through.