I started this as an experiment in using a delay node for capturing and looping. I was going to add it in as another voice on my latest sequencer based patch, but instead I’ve built it up as a four channel loop recorder with solo and external audio supported.
Delay Looper 02.audulus (1.4 MB)
The little demo:
Another little demo (variation on a theme, I guess;):
Basic function
This patch plays loops of various lengths using the delay node built into Audulus. An external tempo source (in my case a drum machine) is analyzed to find the average period of that tempo (for human-powered tempo sources). The looper modules multiply or divide that period by an integer set by a knob, allowing each one to loop over an integer number of beats or to loop an integer number of times per beat, depending whether the setting is greater to or less than one. There’s nothing in the patch that’s actually “clocked.”
The loopers are selected for recording in “radio button” fashion, with only one looper active for recording at a time. Subsequent hits of the button for a channel will cycle it off then on again. A looper can either be erased with each new note played or manually. It can also be allowed to “pile on” notes.
An AGC (automatic gain control) module samples from the mixer the loudness of the loop channels (ch 3 thru 6) and boosts the gain of the solo and drums channel so they can be heard over the possibly ever building loops. Overall gain is maintained by taking that boost back out at the end, effectively lowering the volume of the loops (ch 3-6) while maintaining the solo and drums at their original levels.
Details
On this patch I’m using the white-key scale player module, which has new momentary black key outputs added to trigger the radio button loop record logic.
The button logic module (above) performs the radio button functionality and routes the midi triggers to the loopers as needed. The momentary inputs for selecting current recording channel have buttons in parallel, to allow selection when the white key module is in Chromatic mode (in which the black keys no longer function as switches.)
Solo channel (channel 1)–Tones are produced by my hybrid Osc/Res synth, made from a slightly modified SMOL and my tunable version of the ResDrum. Several params of each are brought out. The output of the synth is filtered by the peaky low pass filter (top item on the screenshot), its cutoff either set by knob or by a frequency (Hz) value presented at that input. Presenting that frequency value is the module, sitting between the looper below and the filter above, which latches the frequency of the last note that was hit and multiplies it by the knob setting. For my use, that knob is controlled in my little rig by the modulation wheel. Filtered output from the solo channel is fed to all loopers.
The in-scale bend module ahead of the synth module allows bends to be played solo or recorded into loops. In chromatic mode (a White-key scale player mode) the bends are chromatic as well.
Loop channels (3-6) Each looper channel is similar to the solo channel, with the exception of a looper module replacing the synth. The loop channels have a similar filter mechanism to the solo channel, with the cutoff above the latest latched tone set by knobs, each of which in the case of my setup is itself controlled by a physical knob.
Looper module. After some experimentation I found that the delay node can be erased by setting its delay and feedback to zero over the previously recorded period. I also found that the node could record an arbitrary length of audio even as it was being erased in the above fashion, playing back once a non-zero loop length was set at the delay knob.
The only hitch I found to this lovely situation was that the sudden change of the delay value on that knob, in the presence of an audio input to the looper, produced an audio burst at the beginning or the end of the loop, building endlessly with each pass. Guessing that this was some sort of “digital domain vs sampled audio domain” problem, and after much trial and error, the best fix I could find was to run the erasing pulse through an ADSR node, with A and R set to zero and D and S set to one. Attempts at filtering either the input signal or the erasing pulse (to cause some delay) failed to eliminate the burst. I don’t have any real idea why the ADSR fix works, apart from the above “hand-waving” guess-planation.
The use of the ADSR node did introduce its own problem into the mix. The main problem being that it introduces a slight error into the period value, effectively shortening the loop relative to the input clock. It’s small enough that for most applications it might not be noticeable, but for extended, Grateful Dead-esque, work you’ll probably hear some slippage.
If I understood the problem better I’d maybe have a cleaner fix. I hate patches like the one I’ve done here. It could break at any moment.
The AGC system is based on a running average calculator module, with rate and sample size set for a reasonable level of responsiveness. The averager I made using a state machine approach. It’s actually way simpler than it looks. Once you go the state machine way it’s hard to go back to crazy point-to-point logic!
I’ve dealt with similar audio issues trying to abruptly change the delay time value. AFAIK the delay is modeled on an analog unit so when the delay value is changed, the unit still attempts to render all the samples in the stream using interpolation rather than simply discarding the intermediate ones. This allows the delay to produce the pitch changes characteristic of an analog unit but results in the noise burst when the value is changed abruptly. Probably the result of trying to produce a whole frame’s worth of data at once. Interesting that the ADSR removes the glitch.
I am stunned, as I usually am when you reveal some new Wonka style contraption that makes everything I have ever made look like Playskool brand toys or building a tower out of LEGO Duplo blocks 
