I’ve written a new version of the AudioFreeze firmware. Now it runs on a Teensy 3.6, so the sample buffer can be 5 times larger. I’ve also added cross-fading (although not when you move the sample window, or play in reverse, that’s on the todo list though), and a broken tape mode. This uses 2 random lfos, one for wow, and one for flutter, to alter the playback speed of the loop. I’m quite pleased with the results.

I noticed a strange issue where it seemed like the audio board was crashing when a high voltage was received from the contact mic. Strange, as I had the on-board attenuator turned up to almost max. Putting another attenuator in front solved the issue, but it needs more investigation.

The Software

Dev environment

The only Teensy based Dev Environment I used was the Arduino IDE. It’s very basic if you’re used to using pretty much any other major IDE. It does the job, but it’s really not ideally suited to large projects. It does something weird when compiling where is merges all your source into a single file (I’m not clear exactly how it does this), which can yield some fairly obscure compile errors due to missing dependencies when working with multiple files. I  did experiment with trying to get Eclipse working with Teensy, but ended up giving up without actually getting it working (I don’t remember what the issue I was having was now).

TeensyJUCE

The lack of easy debugging on Teensy made it tricky to code a module of this size. There were several times when I almost gave up trying to debug where certain unwanted click sounds were coming from. Capturing the output audio and zooming into the glitch in Audacity is not a coherent approach to debugging it turns out.

The majority of the complexity of the code is the effect itself, which is really just about handling audio data, and not platform specific Teensy code. I decided I could be much more productive if I could write this code on my Mac in Xcode with a proper debugger. I wrote a wrapper using the JUCE library which would allow me to do this, called TeensyJUCE. JUCE is a multi-platform API which takes some of the pain out of developing audio plug-ins. It has a similar interface to the Teensy Audio library, in that there is a single function which gets called to process an audio block. All I had to do was reprocess this audio block and pass it to the Teensy effect interface (which had been slightly modified to compile in Xcode). That way I could write my code in JUCE but the effect side would still compile on the Teensy. I then just had to copy and paste the effect module back into my Arduino project, knowing the DSP code was working. This approach definitely saved me some time and frustration, and as an added bonus I then had an plug-in version of my effect to use in my DAW.

The Interface

As you will know from reading Part 1, the interface for the module (or the potentiometers at least) are read using a separate PIC chip, and transmitted to the Teensy via I2C. This uses the Arduino Wire interface, which makes the whole process very straightforward. I’ve tried to encapsulate various types of interface objects in Interface.h, to use in future projects.

I’ve actually started experimenting with the possibility of removing the PIC chip and doing all of the interface reading on the Teensy using the second ADC. I didn’t think this was possible when I started, but have since discovered the ADC library. Will report back with news on how this goes. For now though, to make the code work with the schematic in GitHub, make sure you have I2C_INTERFACE defined.

The Effect

The effect itself is really just an extension of a standard delay line. The delay line is implemented as a circular/ring buffer. To make the most of the Teensy 3.6 256Kb of RAM, and because we are only using the built-in DAC rather than a higher resolution audio codec, all of the samples are stored at 12-bit (even though the Teensy audio library’s native width for samples is 16-bit).

A standard delay effect is often implemented as a delay line, with a write head, which writes into the delay line, and a read head, which reads from the delay line. The separation between these heads governs the delay time. In the Glitch Delay these read heads are actually loops, rather than following behind the write head at a set offset, they instead loop sections of the delay line. There are 3 looping heads, playing the audio at different speeds (one at normal speed, one at double speed – one octave up, one at half speed – one octave down).

When reading audio in this way, you need to be mindful of zero crossing. If you jump around in the audio buffer you will get zero crossing, which will lead to pops and clicks in the output audio. This is resolved in the Glitch Delay by using crossfading. Every time one of the loops is about to restart, it cross fades between the end of the loop and the start. This means reading 2 samples and blending between them. For the same reason, the loops must also avoid being ‘run-over’ by the write head. If the write head were to write over a section of looping audio, you would have both ‘old’ and ‘new’ audio in the same loop, which again would cause a pop. To solve this the loops ‘jump’ out of the way when the write head approaches, this jump must also be cross faded. If you look at the video below you can see the loops and the write head moving around, the orange bar is the write head, the grey bars are the read heads (3 looping, one playing backwards).

Happy New Year everyone! I hope your holiday period was less mired by illness than mine. One of the benefits of not feeling up to leaving the house was that I had time to make a demo video for my Glitch Delay Eurorack module.

The effect is designed around the Teensy 3.6 dev board. I designed the PCB in Eagle and had a small batch manufactured. This is very cheap to do nowadays, only a couple of pounds per board.

The effect consists of a standard delay line, or delay buffer, with multiple read heads that each read the audio in a different way. There is a feedback path, so the effected signal can be feedback into its self.

There are 2 types of read head:

Loop heads – These heads loop small sections of audio. There are 3 of these. One that plays the audio an octave lower, one at the original octave, and one an octave higher. The size of each of these loops can be adjusted (size dial), as can the amount the loops move each time the loop starts again (jitter dial)

Reverse head – This head plays the buffer in reverse at the original octave.

The top white button allows you to set a tap tempo. This forces the looping heads to jump to a new position on every beat.

The bottom white button is the ‘freeze’. This freezes the write head. No new audio will be written into the buffer, the old audio will remain. This essentially ‘locks-down’ the audio, so it can be tweaked without the buffer changing.

How can I build one?

The source code for the firmware running on the Teensy 3.6, and the schematics for the PCB are available on GitHub here

I shall post soon with more details of how to go about creating your own.

Can I use this in software?

Yes! I’ve ported the code to the JUCE framework. You can compile it yourself or download the executables from the GitHub here.

Future plans:

There are still some issues to resolve. The output can be a little noisy. This noise comes from the 5v offset applied to the  incoming audio. This is mainly a gain-staging issue, and could be resolved by having an additional potentiometer to scale the amount of bias applied to the incoming signal. There is another issue where the module occasionally fails to power up. I believe this is due to occasions where the 12v line takes a little time to stabilise, which results in the 5v regulator supplying the Teensy with a voltage of less than 5v for a short period, which causes the Teensy to crash. I have a workaround for this in mind though.

I plan to build an expander module which will connect via I2C which will add CV control of many of the parameters. Check back for updates..

I’ve spent quite a lot of this year (when I wasn’t working on the album) designing a new Eurorack module. It’s inspired by some of the demos I watched of Lines running on the Aleph (by Monome). I’ll be putting up more details soon, but it’s a glitchy digital delay/granular effect running on a Teensy 3.6. I plan to put together a video soon!