Retention Mechanism (2025)
Retention Mechanism is an audio buffer manipulation module originally designed for use in the [Nonlinear] Dynamics system. It may be used as a delay, a crude pitch shifter, as a Karplus-Strong-esque resonator, pseudo-"infinite" flanger, as an unusual oscillator, or as a simple granular sampler/"glitch" processor. By intrinsically decoupling certain aspects of its internal read and write processes, it can generate unusual senses of acceleration or deceleration, broken pitch-shifted echoes, and bizarre phase cancellation artifacts.
Retention Mechanism has been meticulously "voiced" in such a way that it emphasizes irregularities and nonlinearities imposed by several of the audio processing methods listed above. It acknowledges the core conceptual overlap between all of these techniques, and by avoiding the temptation to optimize for any one particular application, it unmasks many "undesirable" artifacts that such optimization is typically designed to hide. In many cases, it brings these artifacts into critical focus: aliasing, wave shaping/distortion, pops/clicks, and the fizz of fuzzy temporal boundaries become a key part of its character. It is meant to amplify the inherent irregularities that emerge when we cease to think about time, memory (retention), speed, and duration in the regimented ways that standardized "effects" have trained us.
Retention Mechanism has some precedents in my own work—it is structurally similar to the Arbitrarily Traversable Memory Register from Continual Transition (c. 2018–2020), the Open-Reel Memory Register from Hypnagogia and Arkansas (c. 2018), and the Windowed Temporal Drag Processor from map12 + map02 (2023). It (and these other devices) is inspired, in part, by cult favorite audio processors from the 1980s, especially the BOSS RPS-10 Digital Pitch Shifter / Delay, RSD-10 Digital Sampler / Delay, and the PS-2 pitch shifter/delay pedal. These were some of BOSS's earliest digital effect processors, developed in a time before many modern conventions for DSP were formalized—and as such, many of their features may seem crude or suboptimal.
Retention Mechanism, in part, is a question: what if we hadn't focused on making audio processing cleaner, more reliable, and higher fidelity? What if, instead, we had focused on all of these devices' eccentricities and used those as a guiding light toward new instrument designs? What would instruments be like today if we had taken that path instead?
Design Inspiration + Development
Romanticization of weird old gear aside, Retention Mechanism's development originally began in the summer of 2024—the same period in which I developed the original core parts of the [Nonlinear] Dynamics system (Destabilized Impulse Generator, Compact Oscillator Network, Voltage Mapping Array, Temporal Drag Processor, Audio Combine, etc.). My original intention was to make something that could function both as a "looper" and as a simple monophonic granular sampler. My vision at that time was that a system might include multiple such modules as a sort of signal processing "backend," and that there might be tools available for performing programmatic changes to their playback speed, direction, loudness, etc. This concept was inspired very much by the fact that I had recently read Gayle Young's biography of Canadian instrument inventor Hugh le Caine, The Sackbut Blues. Among other devices, Le Caine's Special-Purpose Tape Recorder was particularly fascinating; I considered, at the time, how I could incorporate some of its ideas into the instrument that I was developing.
Early tests were promising; however, I struggled to settle on a parameterization that I felt was satisfactory for the features that I imagined it might have. Because the many other components of the system were coming together more quickly and clearly, I shelved the idea of the granular processor. I did revisit the idea briefly a couple of times in the following year, but never landed on a particularly satisfactory outcome. Instead, I turned my focus toward finalizing a basic system design using other components, and by June 2025, I had finished four full [Nonlinear] Dynamics systems—one somewhat larger system for myself, and three identical systems for Vincent Edwards, Todd Barton, and Sarah Belle Reid. I traveled to Ontario for that summer, and took one of the new systems with me.
When in Ontario, relieved of the recent cognitive load of finalizing and assembling the systems, it finally occurred to me that, perhaps, my approach to creating a granular processor had been somewhat backwards all along. What if, instead of thinking of the device as a granular sampler first, I instead thought of it as a delay? After all, what are samplers and delays other than just methods of writing data into and retrieving data from a buffer? And of course, what is a pitch shifter but a means of reading data from that buffer too quickly or too slowly, shortly after it was written there to begin with?
And with that turning point in my perspective, Retention Mechanism's development began. A functional prototype for the firmware was up and running on my generic TEST module within an afternoon; I spent the ensuing days and weeks making minor adjustments and "voicing" decisions. The similarities in structure to the BOSS RPS-10, PS-2, and RSD-10 only occurred to me during this period. I was already very familiar with these devices, and had used them extensively in my own music and production work. Having a deep fondness of their peculiarities, I decided to lean into that direction and let Retention Mechanism be clicky, noisy, and unrefined: this crude brutality became an important guidepost as its development continued.
It became a central part of the sound of the piece/video Artificial Dynamics I. As I was testing the Retention Mechanism firmware, it became clear to me that the Compact Impulse Generator + Retention Mechanism combination was special and warranted further development. Already having felt the inclination toward building more focused instruments, I began to plot out what an extremely compact system centered around these two ideas might be like.
Shortly thereafter, I traveled to Melbourne, Australia with Sarah Belle Reid; I could not, at that time, travel with my full system, but I was eager to continue work on Retention Mechanism. I took a small 4MS Pod case with only a Compact Impulse Generator, the TEST module running Retention Mechanism firmware, and an Output module. Reid and I performed a duo set at the long-running Make It Up Club in which she played trumpet + Max (using a variant of the MultiDelay patch), and I played this small assortment of [Nonlinear] Dynamics modules. I was stricken by the results: it was the first time (after several performances) that I felt like I really had grips of the system as a performable instrument. (I recall that David Chesworth was in the audience, and that we had a lovely chat before I realized who I was speaking with.)
During this trip, I drew up the initial sketches for both Retention Mechanism as an individual module, as well as what would become the self-contained instrument Particle Simulator. (Much of Particle Simulator's PCB layout was executed on the long flight back to Ontario.) I returned to my workshop in Arkansas in August and promptly ordered PCBs and panels for both devices (as well as the Semblance of Fern module, which was in development at the same time). The first Retention Mechanisms were assembled as of September 4th of 2025. They became a prominent part of Sarah Belle Reid's piece Semblance of Fern; Reid used two in her setup for our duo performance at its premiere in Chicago in October. I performed using the first prototype for Particle Simulator.
Shortly thereafter, I began the process of packing up and relocating my life to British Columbia. As such, I went through an extended period without access to the bulk of my tools and materials; I was able, however, to bring Particle Simulator and a small system with me. During this time, I did not create any new modules, but instead chose to focus on continuing to refine Retention Mechanism, especially in its context as part of Particle Simulator. It was during this time that I added the various nonlinear behaviors in the upper travel of the Write control—which added significant depth and character, and to me, truly brought the concept to life. Subsequently, the firmware for the dedicated module was updated to incorporate the same updates.
But that's enough history for now—let's discuss how Retention Mechanism works.
Now + Then
Let's start with the simple stuff. Retention Mechanism is a stereo audio processor. It constantly writes audio signals into a Register (a buffer). The audio source to be written into the Register is determined by the Write Source parameter. With the Write Source control fully counterclockwise, the silence is written into the Register. As Write Source is rotated clockwise, it acts as a scaling factor for the external input—until its center position, at which the incoming audio (the "Now," or "n") is written into the Register at maximum volume (with, in some situations, gentle limiting/wave shaping applied).
Continuing to rotate Write Source clockwise, the write process begins to add an amplitude-scaled version of the instantaneous read audio (the "Then" or "t" signal) into the Register. At around 65% of the knob's travel, both the Now and Then signals are at roughly unity gain and summed. Prior to the summing stage, the Then signal is subject to a specially-constructed filtering and waveshaping process; likewise, after the summing stage, the signals are subjected to yet another gentle limiting/wave shaping stage. As such, Retention Mechanism is seldom (if ever) a clean, precise, or artifact-free device; it almost always applies additional color, noise, and irregularities to the incoming audio.
Beyond 65% of the Write Source knob's travel, the feedback path becomes more complex, enabling several other irregular behaviors; we'll come back to this.
The Source Blend parameter is a sort of expanded dry/wet crossfader. At the "now" position, incoming audio is passed directly to the device's output (though again, subject to yet another soft limiting/wave shaping stage just before the output). Turning gradually toward "then" establishes a variable proportional mix between the direct incoming audio and the audio read from the Register. By around 85% of the travel of the knob, only "then" is audible; beyond this, the Source Blend knob adjusts various parameters related to the amplitude scaling, filtering, and waveshaping of the feedback loop.
Notably, the highest range of the Source Blend knob (the last 5–10%) impacts the amplitude of a feedback loop from the first of eight internal "Read Heads," even when Write Source is below 50%. In this way, when Source Blend is set in its highest range, the first 50% of the Write Source knob can be used as a sort of "send level" control, useful for "seeding" a high-feedback delay process with incoming audio. When Write Source is set to ~65% or higher, this range of the Source Blend knob will have no impact on the amplitude of the internal feedback processes.
Basic Digital Audio Delay Concepts
Perhaps the most dramatic parameters are those used for Register Navigation. These bear analogies to typical delay effects, however, they are implemented somewhat differently than the relatively standard methods for constructing delay effects.
There are two somewhat more common (and probably somewhat more useful) ways of building delays: one which we'll call the Variable Sample Rate (VSR) model, and one which we'll call the Variable Sample Span (VSS) model. In all such models, an internal array/buffer is used as a means of storing audio signals as a series of discrete, sampled values. The array/buffer has a fixed number of indices (ranging from hundreds to millions), each of which stores a single instantaneous amplitude value. When visualized one after another in a line, the contents of these indices approximate the waveform of the "written" audio signal.
In both methods, audio is written into the buffer continuously, from one index to the next, until reaching the end of the table, at which point, the "write head" jumps back to the beginning of the buffer and starts the process all over again. Every storage position is always a valid place for the delay to "put" audio and to retrieve audio from; it simply writes into and reads from the buffer in one continuous, linear/circular pattern, reading and writing from beginning to end, jumping back to the beginning, and so on. This means of conceptualizing the audio storage/retrieval array is commonly referred to as a "circular buffer."
In a single-tap delay implemented using the VSR model, the "delayed" audio is commonly extracted from the index just after the current write position (that is, the position "farthest back" in time from the current write position). Changes to delay time are implemented by varying the slope (or speed, depending on your parameterization) of the accumulation process that determines the index to be written into and read from. This is a sort of "variable sample rate"—and as such, changes to the user-surfaced "delay time" parameter will create a pseudo-Doppler shift effect in which, briefly, subsequent repeats will be speed shifted relative to their original recorded pitch. This is a useful effect, exploited in many devices and pieces of music; and indeed, it is conceptually similar to the behavior of so-called "analog" delays based on Bucket Brigade chips (which essentially use cascades of hundreds or thousands of sample-and-holds for similar purposes to the indices of our digital buffer, described above).
On the other hand, in a single-tap delay implemented using the VSS model, the read/write sample rate is constant. Like the VSR model, it uses a circular buffer, always treating every index of the buffer as a place to store audio or retrieve audio from. However, rather than varying the apparent delay time by changing the read/write speed, it instead allows for continuously-variable relative displacement of the read position from the current write position. That is to say, the "write head" always continuously chugs along at a constant speed, writing audio from the beginning of the buffer to the end, and then jumping back to the beginning and starting all over again. The read head always trails behind the write head by some number of indices. This number—representing the displacement between the two heads—has a conceptual minimum of zero (the current write position) and maximum of the number of indices in the buffer minus 1. Ultimately, this translates to the apparent delay time. Interestingly, with this method, changes to the delay time do not impact the apparent pitch of the repeats: the rate of playback isn't changing, only the displacement between the two constant-speed "heads." Often, in order to mask undesirable artifacts that can result from changes to the displacement value, such delays are actually implemented using multiple buffers and/or multiple sets of read/write processes, rapidly sampling parameter values, assigning them, and crossfading to the secondary process in an (ideally) seamless fashion, such that the existence of two separate delay lines is not apparent to the user.
Retention Mechanism commits to neither approach.
Register Navigation
The above VSR and VSS methods conceptualize their internal buffers as a continuous loop which must be traversed in its entirety, in a linearly-advancing circular fashion—constantly tracing the perimeter of the circle in one direction. Retention Mechanism instead offers arbitrary access to all regions of that circle.
The read/write regions are governed by the same set of Register Navigation controls. The Position control determines the starting position in the buffer for the read/write process; the Window control determines the number of indices used in the current region (from extremely small window sizes to the size of the entire buffer). The region specified by the Position and Window values is the only region utilized at any given moment for the read and write processes. The rest of the buffer remains untouched.
So, in concept, if you have Position at minimum and Window at 50%, then the first 50% of the buffer is utilized for the currently-sounding delay effect, and the rest of the buffer is unaffected. If audio had previously been written into that other portion of the buffer, it would remain there until the Position and/or Window values are such that that region of the buffer should be used as part of the read/write process. Both Position and Window are voltage-controllable, and as such, modulation can result in the unexpected re-emergence of latent/dormant/"old" audio which had been lurking in some dark, distant recess of the buffer. In some cases, you may not have heard these sounds in several seconds, minutes, or hours—but they, of course, had been there all along, waiting for their time to recur.
While it principally serves as a means of defining a delay time, the Window parameter exhibits many unusual behaviors, especially in the lower half of its travel. In this range, it focuses on extremely small time windows, resulting in unusual aliasing, evolving self-oscillations, and many "broken" flanger/phaser/comb filter-esque textures.
Audio is always written into the selected region at a constant rate; however, the Speed parameter determines the relative rate of the read process relative to the write process. As such, one can think of the Speed control as determining a speed shifting factor relative to real time, ranging from one-eighth "real" speed up to eight times the "real" speed. In conventional musical terms, one might think of this as a means of shifting the pitch of the playback signal anywhere in the range of +/- three octaves. This can be used to create pitch shifting effects, pitch shifted echoes, or to augment some of the device's capacity for flanger/phaser-like textures at extremely low shift amounts.
Because the Speed shifting functionality is executed simply by unlinking the playback speed relative to the read speed—and because both the read and write heads always occupy the same region of the buffer (as determined by Window and Position)—the Speed parameter also introduces audible discontinuities which increase in regularity and intensity the more shifting is introduced. This can result in glitchy, stuttery repeats or abruptly-truncated echoes. It is, in a way, a crude or naïve means of implementing pitch shifting—however, my goal was not explicitly to create a pitch shifter, but to create a device that exploited some of the interesting behaviors that emerge from unusual parameterizations for buffer manipulation processes. These irregularities are a natural part of the underlying algorithm, and play an important role in defining what ultimately became Retention Mechanism's "sound."
Hold + Reverse
On the bottom right-hand side of the module, there are two tactile switches and corresponding trigger inputs: Hold and Reverse. Each act as "toggles," with their respective trigger inputs also serving to toggle their state.
Hold is a means of effectively pausing the Write process, ensuring that no new data enters the buffer, and no data currently in the buffer is overwritten (think of it as a sort of Write protection). It can be used to create stutter/repeat-style effects, and is key to Retention Mechanism's many uses as a sort of sampler. When audio is Held, all other parameters are still active.
It can be especially gratifying to record audio into the buffer, Hold it, and then use the Register Navigation parameters to perform simple granular sampling-like manipulations of the stored audio. The Window parameter becomes similar to a "grain size" control; Position becomes similar to a "Slide" or "Start Position" parameter. One may, of course, disengage and re-engage the hold function performatively, populating the buffer with a microcosmic collage of distinct audio materials for later "granularization" (of sorts). One might narrow in on especially small window sizes, treating the modular more like a sample-based oscillator where Speed controls the apparent pitch and Position controls the waveshape. Similarly, one might modulate the Window parameter within a relatively small window to create formant-and-pitch-shifting-like effects.
The Reverse function reverses the direction of the read head, while still respecting the boundaries established by the Window and Position controls. The moment the function is activated, the "phasor" corresponding to the Read position is not reset—it simply shifts direction. As such, rapid repeated activations/deactivations can be used as a sort of means of generating a rhythmically synchronizable "stutter." Otherwise, the function behaves as you'd expect: it reverses things. Note that, when Write Source is set to a position that introduces feedback, successive "repeats" will seem to shift between forward and backward playback. This is normal (or, well, as normal as it should be).
Write Source: the Far Reaches
Oh yes—we mentioned earlier that, beyond ~65% of the travel of the Write Source knob, things get...peculiar. Let's dig into that.
For all practical purposes, when Write Source is below ~65%, Retention Mechanism uses a single read head. However, Retention Mechanism contains eight such read heads, all governed by the same set of parameters. The last ~35% of the travel of the Write Source control allows data from these additional heads to be written into the buffer and/or routed directly to the audio output summing/filtering/waveshaping network.
Low in this range, Retention Mechanism tends to self-oscillate, producing resonant tones that resemble acoustic feedback in a variable-size space. As the knob is rotated clockwise, the relative loudness and timing of the eight read heads gradually shifts, providing access to multi-tap delay sounds which range from different varieties of spectral accentuation, resonance, and accelerating / decelerating echo rhythms. The effects of the upper reaches of the Write Source parameter can be quite profound, especially combined with the Hold function: it can produce effects similar to comb filtering, phasing, and more.
Retention Mechanism has become a staple part of the [Nonlinear] Dynamics system. As of February 2025, five units have been built, spread across five systems. It is a central part of Particle Simulator, and will feature prominently in other forthcoming self-contained instrument designs and future refinements of the modular system.