Category: Tech

  • MLR inspired looper.

    I’ve never owned a Monome, but always loved them. They look beautiful, the apps are inspiring, and let’s face it, they revolutionised midi controllers. There’d be no Launch Pad if it weren’t for the Monome Grid. One of the very early apps on the Grid, was MLR, designed by Brian Crabtree, the creator of Monome.

     

     

    I wanted to try and create something similar to this, albeit a crude and inferior version. I’ve designed an add-on board for my Cutlassiezer PCB, as used on the Glitch Delay. This is based around a PIC chip which communicates to the main Teensy based board via I2C.

     

     

    In this video, the Kalimba is being amplified by the Microphonie, and then into my KhronoKrusher delay module, then into the looper.

     

    On the main board you can see prototyped on vero-board, the PIC uses a shift register to shift a single ‘ON’ bit through the register. At each bit location, the ON bit can optionally turn on the LED and read the value of the associated switch. This technique was borrowed from the Le Strum by sixty four pixels. The Teensy sends the desired LED states across the I2C bus, and the PIC chip sends back the current state of the switches. Here’s the schematic from Eagle (click to view an enlarged, readable version).

     

    This is just a work in progress at the moment. I’ll give further updates as I progress. As always, the code is available on GitHub here.

  • Piano Music

    In the run up to Electromagnetic Field Festival which I played earlier in the year, I was preparing for a performance using only instruments and effects I’d built myself, either from kits or of my own design. The problem was, most of my modules are effects, they transform sound, but they can’t really generate sound from nothing. I had an idea to make a module which would just play piano sounds controlled by CV and gate. Here’s a video of the performance, similar to the one I played at EMF.

     

     

    The Piano Player module

    I decided to base the module on Music Thing Modular’s Radio Music/Chord Organ module by Tom Whitwell. It already has inputs for CV and Gate, and is Teensy based, which I’m well versed in. Time was limited so I didn’t want to have to build the hardware as well as write the software. I ordered the module from Thonk as well as a Penrose Quantiser, although I didn’t have time to build this in the end, so ended up doing the quantising in software.

    The Teensy 3.2 has fairly limited memory (64k ram, 256k flash), so I only had space for a single piano sample, which is stored in the flash memory. I then had to write the code which could play this sample back at any pitch, using cubic interpolation to smooth the resulting sound. I wanted the module to have polyphony, so the sounds could overlap, without cutting off the tail of the previous sample. The Teensy 3.2 doesn’t have a floating point unit. This means it has to emulate all floating point (fractional numbers) in software, which is very slow. Initially I struggled to achieve multiple voices at once due to poor performance. I solved the problem by writing a fixed point maths library. This replaces floating point maths calculations with integer based ones, which are faster. You do accrue some loss of accuracy doing this, but it was almost x10 faster, and I was unable to hear any artefacts. This extra boost in speed gave me enough remaining CPU power to add reverb, using the freeverb algorithm in the Teensy audio library. See the source on GitHub for more details.

    In this video, the Piano module is being fed random voltages from the Turing Machine (also from Music Thing). I then quantise this signal internally in software to be in the key of C. Once I’ve built my hardware quantiser I can remove this step. Theoretically this module could play any sample, the sample just needs turning into a .h include file which can be included in the source of the project. I created this using wav2sketch. If you want more samples, or larger ones, you’d need more memory. A Teensy 3.5 could be used to achieve this (as I use in some of my other modules). It does look like you could physically fit this onto the Radio Music board, the only problems I can see might be power related issues, such as discussed here http://www.cutlasses.co.uk/tech/redux-the-redux/

     

     

  • Passive Mixer

    I needed a way to mix the audio from the modules I’d built recently. As Eurorack signals are generally rather hot, running 10vpp (considerably higher than line level), I thought a passive solution made sense. The circuit was very simple so I put it together on vero board. A new lesson I have learnt is, be careful where you source your pots! I ordered 8 cheap from China and had issues with all but 2 of them, which resulted in hours of needless debugging.

    I wanted something to make the project slightly more interesting, so added a kill switch for each channel. Partly because I thought it would be useful, and partly because I liked the look of these tactile switches!

    I housed the mixer circuit in a small hammond aluminium case, really glad I bought a pillar drill!

     

    Veroboard wiring

     

    Drill holes

     

    Changed my mind on the choice of knobs

  • Redux the redux

    I’ve had a couple of interesting comments on my AudioFreeze/Glitch Delay module which have contributed to revising the PCB, details of which can be found here.

    1. Why is it so big? Good question! The original AudioFreeze is pretty wide, and that’s because the PCB itself is pretty much that wide. I set out to create a smaller PCB.
    2. Why not use the second ADC on the Teensy 3.6 instead of the separate PIC chip? Well, mainly because I’d missed the fact that it had 2 separate ADCs, but I’d been led to believe that this was not possible by people on the Teensy forum, it turns out it is possible, but it’s not totally straightforward.

    Here’s the finished, reduced size module

     

     

    Reducing the size of the PCB

    Getting rid of the PIC chip reduced the number of components, which meant the PCB could be smaller. Also, I split the module into 2 PCBS. One which has the Teensy on and the audio and power circuits, the other has the interface, the pots, jacks and buttons. The PCBs stack, separated by header and copper spacers.

     

     

    Removing the PIC chip

    The previous version of the board employed a PIC chip to read all of the potentiometers and pass the values back to the Teensy via I2C. It transpired it was possible to achieve this all on the one board, see here for source code. The ADC library for Teensy allows you to access the 2 ADCs on the 3.6 individually. There are currently a couple of issues with this in the Teensy libraries. One of them is that it’s very important the ADC is initialised before the Audio Library (see struct IO – this enforces initialisation order). Secondly, the Audio Library runs at a reference voltage of 1.2V. Because the potentiometers are connected to the 3.3V line, you need to set a different reference voltage for the 2nd ADC. There is functionality to do this in the ADC library, but it doesn’t work (for a couple of reasons, which I’ve raised on the Teensy forum here). I fixed this by setting the registers directly (see set_adc1_to_3v3())

     

    Power issues fixed!

    The previous board also had issues where it just wouldn’t start up when connecting to certain power supplies. It turns out, this is due to the time it takes for the 12V line to stabilise. If it takes to long, the 5V line won’t be at 5V whilst the Teensy boots, and it crashes. This explains why, if I powered the Teensy over USB and Eurorack power, then removed the USB, it solved the problem, although felt like ‘jump starting’ it, like an old car! Thanks to the Teensy forum and BCP Music for this information. The solution was to use a voltage supervisor (MIC803). The keeps the Teensy in ‘reset’ until the supply has stabilised.

     

    So far I’ve made up 3 of the PCBs, all running different firmware (shown here in a DIY case, with a combination of aluminium and laser-cut acrylic panels).

     

  • AudioFreeze Redux

    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.

     

  • Glitch Delay – How it works part 2

    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).

     

  • Glitch Delay – How it works part 1

    The Glitch Delay is the Teensy based eurorack Delay module I designed that you can read more about here. The video shows what it sounds like, but I thought I’d go into some more detail about how it actually works, and how I went about designing it.

    The Hardware

    The brain of the module is the Teensy 3.6. The code running on the Teensy uses the Teensy audio library, and implements a new AudioStream. Because the in-built ADC of the Teensy is used by the audio library, we need another way to read the potentiometers, this duty is performed by the PIC. The PIC reads the pots and communicates the values to the Teensy via I2C (a well supported and fairly simple protocol for inter chip communication). Op-amps are used on both the input and the output to scale voltages up and down. You can find the complete schematic here, but I’ll go into detail on the major sections below. Many elements of this schematic are cribbed/stolen from other open source schematics. I’d highly advise checking out the circuits behind the Music Thing and Mutable Instruments modules whose schematics are all up on GitHub. I’m a relative beginner when it comes to electronics, so it’s highly likely there are elements of this schematic that are not best practice or wrong in some way, feel free to email me with feedback and corrections!

    Audio input/output

    Audio schematic

    Audio In

    The purpose of this section of the circuit it to scale the modular audio signal from (-5V to 5V), into (0 to 1.2V). 1.2V is the voltage of the internal reference in the Teensy. 5V is added to the incoming signal to bias it to be 0V and above. This circuit is an op-amp summing amplifier similar to this.

    When Vin = -5V
    Vout = ( -(5/8.3) + (-5/8.3) ) = -1.2V (approx)
    When Vin = 5V
    Vout = ( -(5/8.3) + (5/8.3) ) = 0V

    As you can see, this has inverted our signal (the op-amp is in an inverting configuration), so the second op-amp inverts it back again with a gain of 1 (e.g does not change the magnitude of the voltage, it simply inverts the signal)

    Audio Out

    On the way out we want to do the exact opposite. Scale from (0 to 1.2V) to (-5V to 5V) this is achieved using a simple inverting op-amp.

    The gain of the circuit is:
    Gain = -(Rf/Rin) = -(100/12) = -8.3
    Max voltage from Teensy = 1.2V
    1.2 * -8.3 = -10V (approx)

    As you can see, this inverts our signal, so the signal is passed through another inverting op-amp with gain 1. The output of this chain will be (0V to 10V) (actually 9.6V, because we are limited by available resistor values). There’s no need to bias, the output capacitor AC couples the output, blocking direct current. Meaning the output signal is centred around 0V, and therefore (-5V to 5V) again.

    I found the power line to be quite noisy. I tried using an external voltage reference, instead of the 5V power from the regulator but didn’t notice much improvement. Everything is fine if the gain-staging is sound. However, with very low input volumes/voltages you will hear noise when you amplify the output. In future I would add a trimpot or panel pot to adjust incoming voltage (e.g. R1).

    Teensy

    Teensy schematic

     

    The Teensy’s main duty is to do the audio DSP. It is connected to the PIC chip via I2C. This uses the SCL and SDA pins on the Teensy (with pull-up resistors to the power line). See here for more information. On the Teensy this is supported through the Arduino Wire interface, and is very straightforward. I shall go into more details on the software running on the Teensy in future posts. The Teensy also controls the LEDs and reads the push switches. There are lots of pins on the Teensy, so it seemed best to connect them here. It could have been done with the PIC, but there aren’t enough pins so you’d need to use a multiplexer.

    PIC chip

    PIC schematic

     

    The PIC chip is connected to all the potentiometers. It reads their values and passes the data to the Teensy via I2C. I’ve connected the programming pins to header so it can be programmed on the board. There’s also a connection for an LED for debugging purposes. Neither of these are strictly necessary, but are very useful at the prototyping stage. The capacitor to ground on the power line is as per the data sheet, presumably to deal with minor fluctuations in voltage.

    PCB design

    All of this was designed in the free version of Eagle. A very powerful, but rather infuriating piece of software (the UI leaves something to be desired, although is getting better). After you’ve designed the schematic you have to layout the board. This is a fun and at times tricky puzzle game. You need to route all of your connections without crossing over another track on that layer. You can use vias to change to another layer of the board which makes things easier. It’s definitely worth spending some time experimenting to get a layout you are pleased with. You’ll end up with something that looks like this.

     

    Glitch delay board layout

     

    You can then send it to a PCB fabrication house to get it made. I used Hackvana, who I was very pleased with. There are a number of alterations I would make on a future board, a major one being that the power connector is too close to the Teensy, meaning I have to improvise a little on the connections. That said, it did work first time, which isn’t bad for a board of this complexity.

     

     

    In further posts I shall go into a bit more detail about how the software works, and further developments.

  • Glitch Delay

    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..

  • New effect on the way

    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!

     

    Glitch delayglitch delay drill template