• Filtering / Second PCB Design

    Matt Bradshaw05/09/2019 at 22:38 0 comments

    I feel like I have a handle on the noise issues now. Part of the issue was the PWM noise (Mozzi generates audio via pulse width modulation rather than a "proper" digital-to-analogue converter). The Mozzi website gives a useful low-pass filter circuit for filtering out this noise, but I found that it wasn't sufficient once I started amplifying the signal. Although the signal is only just within my range of hearing, I could tell from recording the signal into my computer that there was a lot of high-frequency oscillation that I wanted to get rid of.

    I played around with different resistor and capacitor values, but found that in order to filter out enough of the noise, I was also having to filter out the higher frequencies of the drums, leaving an unwanted muffled sound. I searched the web for "make steeper low-pass filter", and suddenly felt like I was back at university again. I came across this great explanation of passive low-pass filters, which had a really useful section on building a second-order filter. This is basically a chain of filters, and gives a steeper "roll-off", cutting out more of the unwanted frequencies (about 15kHz and above) and keeping more of the frequencies that actually contain drum sounds. I played around with a few different components (why are ceramic capacitors so hard to read?) and found a sweet spot, meaning I was ready for my next PCB...

    There are a few key differences from the first version:

    • LM386 amplifier for louder headphone signal (friends told me the last version was too quiet)
    • Different button layout after testing the first design
    • Three control knobs instead of one after testing the first design
    • Different type of button - the previous ones were hard to source and impossible to find with an RoHS certification, which is worth thinking about before I start selling DrumKid
    • Bigger on/off switch for better ergonomics
    • Horizontal thumbwheel volume control for better aesthetics
    • Mounting holes because I forgot them last time
    • Better power management - decoupling capacitors for the Atmega328
    • Arduino and power pin breakouts for better hackability

    I'm still learning about board layout, and should probably get some professional feedback at some point, but for now I've got my fingers crossed that this will be a good improvement on the previous PCB. Now I've got about three weeks before the boards turn up - I could have shelled out the extra money for fast shipping, but I need some time to work on the code anyway, so I'm happy to wait.

    Next steps: more work on the code, 3D-print a new case, try DrumKid with my band.

  • Working Through The Frustrations, Slowly

    Matt Bradshaw05/07/2019 at 13:53 2 comments

    After yesterday's rant about not knowing what to do next, I decided to invest some time in making a new stripboard prototype. I was worried that the current design (batteries to voltage boost IC to Atmega328 to LM386) was just fundamentally too noisy, yet I couldn't think of a way to omit any of those elements without going all the way back to the drawing board. With this worrying thought in my head, I decided to convert my latest breadboard circuit into a stripboard circuit, in the hope that I would be able to build something with a clean enough audio output to give me some hope for the PCB version. It was a half-logical, half-desperate step, but (after several tense hours) it just about worked.

    Before adding the decoupling capacitors, the noise was still horrible, but I tried adding a few different values to both sets of power/ground pins on the Atmega328 and gradually the noise became almost acceptable. Perhaps "acceptable" is a bit strong, but given that the stripboard circuit doesn't have a proper ground plane, I'm happy enough to now recreate this as a PCB, with slots for numerous decoupling capacitors.

    Apologies that the last couple of posts have been a bit dull - I'm trying to be disciplined and sort out the fundamental issues like power supply, audio volume, and noise, before I keep working on the fun features.

  • Frustrations

    Matt Bradshaw05/06/2019 at 17:02 0 comments

    I'm reaching a tricky point in the development process. Skills-wise, I'm someone with a fairly good grasp of coding, but only a patchy (if gradually improving) grasp of electronics. This means that, while I'm pretty capable of solving weird software problems, things like grounding issues or noisy power supplies send me into a cold sweat.

    I've never really had to worry about problems like this before this project, because I could always avoid them. My previous musical instrument builds were one-offs, and I could choose a platform that didn't require me to do much "real" electronics. For instance, a lot of my recent instruments have used a Teensy 3.X (£20+) with a Teensy audio adaptor (£13), which instantly gives lovely clean audio and plenty of processing power. I also power most of my projects with a USB power supply rather than batteries, which simplifies things.

    DrumKid, though, is my first attempt at a real-world "product", and developing it is a very different process. I've used a £2 Atmega328 chip to try and keep costs down, but doing so is causing me all sorts of problems that I wouldn't hit with a Teensy. I can't just put £33 of extra components in there, though, because I'll then have to put the price up by that amount. Then again, with the better components, it's probably a better instrument and probably worth more, so maybe that's okay. And by using a Teensy instead of an Atmega328, I would probably save myself a bunch of time and money on the development process.

    The problem is, I have no idea how to do the calculations that would tell me whether my current strategy of trying to be as cheap as possible is the right one. I've also sunk a lot of time into this design, and I don't want to change tack, which I know is bad logic.

    Anyway, my current problem is this: DrumKid works nicely when using a proper Arduino and a nice clean 5V power supply for testing, although the audio is a little quiet. I can boost the audio with an LM386 amplifier, but then it becomes really important to have a clean power supply. The finished product will be powered by batteries, run through a boost converter to get to 5V, and it's quite hard (but possible) to get that power supply clean enough for good audio. Basically, everything should work fine together, but when I try all the elements together on a breadboard, I get horrendous, unacceptable amounts of noise. Now, I know that a solderless breadboard is probably not the best way to test a fairly sensitive circuit like this, but I don't know what else to try. Is it worth spending time making a stripboard version? Do I have to resort to doing another iteration of the PCB, knowing that it probably won't be the final one, and might not even work?

    I think I'm starting to see the difference between being a "hacker" and a "designer"...

  • Metamorphosis + Audio Sample

    Matt Bradshaw04/24/2019 at 15:41 1 comment

    Spent a good day working on the project today, and made a few decisions about the design. While looking back at the initial, web-based version of this drum machine, I remembered that the most pleasing thing about the interface was changing multiple parameters at once, by touching the different sliders on the touchscreen. This was previously something I had decided to sacrifice for this physical version, in favour of having one big potentiometer whose function could be changed by pressing different combinations of buttons.

    Today I decided to experiment on the breadboard with three potentiometers, and only five buttons instead of seven, and it definitely felt nicer, so I'm going to carry on with that layout for now - I think it will look just as good (if not better) when translated into a new case design, and will only raise the component cost by £1 or so (although I've said that about a few components recently, so it's probably time to do another cost check soon).

    I've also spent quite a bit of time on the code today, implementing a system which loads two copies of each audio sample, allowing them to overlap with each other. Before I added this feature, a loud bass drum followed immediately by a very quiet one would cause an annoying "click" sound as its signal was suddenly attenuated by the quieter sample which replaced it.

    This system is working nicely, but it is a bit more processor-intensive and has consequently caused me to get rid of the resonant filter effect. Analogue filters are really cool, but this was a fairly weedy-sounding digital filter, and I don't think it's any great loss.

    To show where I've got to so far, I recorded a sample of how DrumKid sounds in its current state. The following recording starts off "clean", with no additional bit-crush effect, although it's still pretty crunchy (a feature not a bug!). I begin by adjusting the "hyperactivity" parameter to modulate how many extra hits are added to the basic beat. Then I start to increase the bit crush effect while also modulating the pitch of the samples. The only post-processing I added to the recording was a low-pass filter, because I could still hear a faint high signal (Mozzi's carrier signal?) which I haven't successfully filtered out on the breadboard yet.

    Here's the recording: 


  • DrumKid: A History

    Matt Bradshaw04/24/2019 at 05:31 0 comments

      Work continues apace on DrumKid. A brief update: I took the prototype to the pub to show some friends, who unanimously concluded that it was "cool" but "too quiet" through headphones. I had been hoping to avoid this problem - the better I clean up the output signal (using an RC circuit), the quieter it becomes, and it's now officially too quiet to contend with the background noise in a pub garden. I've been reluctantly playing with an LM386 amplifier chip, with a mixture of success (it's louder) and frustration (the noise from the power supply is also louder).

      Anyway, I thought I'd write a bit about the genesis of DrumKid, since it already existed in another form before this Arduino-based iteration of the project. A few years ago, I decided to start a band. I found a bassist and a synth player to complement me on guitar and vocals, but I didn't want to use a drummer. My opinion was that having real drums in a band always pushed my music towards a pastiche of rock, so I wanted another way of generating rhythms, something with the expressiveness of a good drummer but without the robotic tendencies of a simple drum machine.

      At the time I had been playing with the Web Audio API (the surprisingly full-featured Javascript synthesizer engine found in modern browsers), and stumbled across this article about scheduling precise drum hits in Javascript. I stole the code, spent a long time playing around with it, and ended up with a web-based drum machine I called "DrumKid".

      Screenshot of the original browser-based DrumKid

      The basic premise was/is to start with a simple drumbeat (e.g. kick, snare, kick, snare), then modify it with a number of continuous controls (sliders). The main controls are:

      1. "Hyperactivity" - how likely the algorithm is to add an extra drum hit on a given step
      2. "Zoom" - changes the subdivision of step which can be heard (on its lowest setting, only the first beat of the bar is heard, but the highest setting will allow 64th-notes, sounding much more "hectic")
      3. "Ceiling" - silences any notes below a certain threshold, creating a less "busy" sound
      4. "Blend" - interpolates between two different basic drumbeats
      5. "Sloppiness" - shifts the timing of each step by a random amount (basically a random quantize function)

      These parameters, and especially the first two, could be manipulated in real time to produce dynamic, non-robotic beats. I also added a number of audio effects such as resonant filter, delay, reverb, and pitch shift.

      The interface was optimised for a touch screen - I would borrow the iPad from my office, tape it to a music stand, and our bassist would control it during songs. He modified his playing style to allow him to control DrumKid while also performing bass duties, for instance by playing a long, loud bass note which would sustain for a couple of bars while he increased the "hyperactivity" and "zoom" controls before a chorus. Here's a video of our band, Robot Swans, in action with DrumKid a few years back:

      We made a whole album with DrumKid, The Tyranny of Robot Swans, and a few of our friends used it in their own music. When our bassist left the band, we changed our style slightly and DrumKid fell out of use for a while, but I had always held onto the idea of making a proper, standalone physical version of it. When I decided to leave my programming job and become a freelancer, I soon focused on the idea of making my own off-kilter musical instruments, and DrumKid seemed like the ideal first project. It can be made small, and doesn't require much processing power, allowing it to run on an ATMega328. I've had to compromise on a few things (audio quality is reduced, reverb is unlikely, not all parameters can have their own knobs, etc), but the limitations of the Arduino version are actually making it more rewarding to develop for - squeezing extra features out of a £2 chip becomes almost like a game, and I've been able to add things like bit-crush which weren't in the original Javascript design.

      If you'd like to play...

    Read more »

  • 3D-Printed Prototype

    Matt Bradshaw04/17/2019 at 15:56 0 comments

    I've printed my first attempt at a case for DrumKid. It's still a long way from a finished instrument, but it's a great start - it feels awesome to see, hold, and use a thing that until recently only existed as a drawing. My current plan for the final product is to laser-cut the design as layers of wood, so I wanted to make a prototype which could theoretically also be made on a laser cutter. With this in mind, I used a uniform thickness of 3mm (which seems fairly standard on laser cutters) and didn't add any features that couldn't be build up in layers if need (i.e. the basic shape is a prism). Here's what it looks like from the front::

    The finish is very rough because I printed the main part face-down, to avoid needing supports. For annoying reasons, my printer basically forces you to print everything on a raft, which is difficult to remove on larger prints like this, causing the pock-marked surface. I could avoid this in future by printing the case in sections, or by printing the other way up, with supports, but my priority for this build was speed. You can see a somewhat nicer finish on the back and sides of the instrument:

    Here's what the case looks like with the back removed:

    And here's what it looks like when entirely disassembled:

    The plastic button plungers (is that the right word?) push down on the buttons on the PCB. Getting the correct dimensions took a bit of trial and error, but the buttons now work nicely. The chunky power slide switch also works well. The two knobs probably need a bit more work, but at this stage I wouldn't be averse to 3D-printing all of these small parts in the final product. They are quick to print and could look pretty cool if printed in a bright colour, contrasting with the look of the wood.

    Printing everything took roughly 10 hours. I could optimise the design to print more quickly (and with a better finish), but it will probably never be quick enough to be viable for the final product, which is the main reason I am looking at laser-cutting.

    In case anyone is interested in how I designed the case, I used FreeCAD (which is free and open source). I sketched the design on paper first, then worked out the measurements of the lines and bezier curves that make up the outline. I drew this outline using "draft mode" in FreeCAD, then extruded it into a 3D shape. Almost everything else in the design is either a cylinder or a cube. Here's what the design looked like in FreeCAD:

    Overall I'm really happy with progress so far. I've got a working PCB inside a decent, functional case, and I can now do some proper development work, iteratively improving the Arduino code to create a fun, intuitive instrument. However, there are a few things (besides those mentioned in my last log) that I have now realised I need to improve:

    • The inductor and capacitor stick up too far from the PCB, meaning the board has to be mounted too far from the face of the instrument, preventing the potentiometers from protruding far enough through the top, and meaning that the LEDs are more recessed than would be ideal - mounting the tall components at right-angles, flat against the board, in the next version will hopefully solve this problem
    • The PCB needs four mounting points, not two (it actually has none at the moment, but I drilled two holes for this prototype, thinking it would be enough) - more secure mounting gives a better feel when pushing the buttons
    • The volume knob looks ugly and should be moved, either to the bottom-middle of the front, or alongside the power switch and headphone output

    My next priority, though, is to spend some time adding features to the code. Hopefully the next log will contain an audio sample :)

  • First PCB Working

    Matt Bradshaw04/11/2019 at 10:05 0 comments

    It's alive!

    Ordered 10 PCBs from JLCPCB, which arrived while I was on holiday. They didn't seem to suffer from the postman having left them under the bench behind my house in rainy England for several days. I ordered a few remaining components and soldered everything in place.

    Nervously, I turned on the power and... success! Well, almost. The ATMega328 runs fine from the two AAA batteries via the MAX756 voltage regulator, the LEDs work and the volume control works. Drum sounds comes out of the headphone socket, but the unwanted high-frequency noise from the breadboard circuit is, despite being quieter, still definitely present.

    Knowledgeable people may be able to spot the problem simply by examining the photo of the PCB - I'm pretty sure that I need to add one or more decoupling capacitors close to the ATMega328's power pins. Powering the original breadboard design straight from 5V sounded fine, with the high-frequency noise only appearing once I employed the batteries and voltage regulator, so the problem was almost certainly a noisy power supply.

    After some haphazard googling, I realised that adding capacitors would likely clean up the 5V signal and therefore solve my problems. I tried adding some capacitors to the breadboard design, and the noise was instantly and dramatically reduced, which was a big relief. I don't know of a good way to bodge several capacitors into this PCB, plus there are a few other imperfections, so I think I'll make a second revision, which might even end up being the final version if I'm lucky.

    Here are my current thoughts for a second revision:

    • Add decoupling capacitors - maybe even leave holes for more capacitors than anticipated, so I can experiment with different arrangements of multiple decoupling capacitors (apparently different values of capacitors in parallel will suppress different frequencies of noise)
    • Move the voltage regulator closer to the microcontroller to further reduce noise
    • Move the headphone socket (and power switch?) closer to the edge of the board - this will make case design easier
    • Move the capacitor which is currently directly behind the headphone socket, so that I don't bend it with my thumb every time I plug in my headphones
    • Rotate the potentiometers, which are currently mounted sideways (idiot)
    • Add mounting holes, preferably in Lego-friendly dimensions to improve hackability
    • Possibly add "breakout" holes either side of the ATMega328, partly to aid debugging/design, but also to make the design more hackable by others (e.g. breaking out the RX/TX pins would enable a hacker to add MIDI input/output)
    • Maybe even leave space on the top panel for optional MIDI in/out sockets
    • More/better labelling - add component values, maybe label the ATMega328 pins with their Arduino pin names, and maybe also add some fun graphics because why not?

    For now, though, while I've got a working (if noisy) PCB, I'm going to concentrate on case design, because I'd like to know if there are any problems with the layout of buttons and knobs before I design a new PCB. Here is my rough plan for the next couple of weeks:

    1. Design and 3D-print a simple case for DrumKid - the final product is now unlikely to be 3D-printed (probably made of laser-cut wood layers instead), but 3D-printing will allow me to rapidly test/iterate the dimensions/ergonomics
    2. Do some more work on the code - the current Arduino sketch which is loaded onto the ATMega328 is really just a proof-of-concept, designed to test whether the buttons, knobs, scheduled sample playback and audio effects work properly. The "aleatoric" element, which is really the heart of the DrumKid concept, has not yet been implemented, so this is a good next step - adding this, in conjunction with a basic case, will give me a first proper, testable prototype which I can try out with my band
    3. Design the second version of the PCB and order it

  • PCB Design

    Matt Bradshaw03/23/2019 at 02:09 0 comments

    Quite early on in the process of designing this version of DrumKid, I hit upon the idea of making it look like a handheld games console, or possibly a game controller. I thought this would make it easy to play, and would give it a fun aesthetic. I sketched a simple design, tried to imagine playing it, made a few adjustments, and finally settled on it.

    Rough sketch of DrumKid - the thing that looks like a directional pad is actually a knob, and the "screen" is just for show, not really a screen

    The design would allow me to keep the PCB below 10cm by 10cm, which keeps the cost down, with space to spare for a battery compartment at the bottom.

    I'm pretty new to KiCad. I've only designed one previous board (a timer with an LED display), but it did end up working, so I was optimistic about being able to design a decent PCB for DrumKid. In case anyone's interested, I learnt KiCad from Shawn Hymel's excellent YouTube series: 

    While creating the schematic in KiCad, I realised that I was only using 9 of the Teensy's 20 pins, and in a fit of immaturity decided to add five LEDs to the PWM pins. My reasoning was a) they might be useful for visual feedback, b) LEDs look cool, and c) if I decide not to use them, I can just not solder them and I don't even have to revise the PCB - win-win!

    My second-ever PCB design - this has already been sent off for fabrication, but please let me know if you see any obvious mistakes because I'm new to this!

    Anyway, I made the schematic, laid out the board, generated Gerber files and sent the design to JLCPCB. I'm off on holiday for a week, but hopefully the boards will arrive not long after I'm back, at which point I can solder everything in place and see if it works.

  • Breadboard Prototype

    Matt Bradshaw03/23/2019 at 01:21 0 comments

    I already put quite a bit of effort into developing the DrumKid concept while it was just a web app, and got it to a state that I'm pretty happy with. Once you've got the hang of playing it, it's a fun, interesting device that can be controlled even while playing another instrument. This meant that the development process for the Arduino DrumKid was mainly about the practicalities of transferring a screen-based web app, running on a powerful computer, to an Arduino with some buttons and knobs.

    I quite quickly settled on Mozzi as my Arduino audio library of choice, because I've used it before and was impressed with it. It's relatively lo-fi, but then the original DrumKid happened to produce lo-fi sounding beats anyway, so that's fine.

    I drew up a list of initial specifications for the device that looked something like this:

    • Should be cheap to build
    • Should be small and portable
    • Should run off batteries
    • Should be easy to play
    • Should look cool

    Once I'd got a basic drum beat playing on an Arduino Uno, with a few simple effects controlled in real time, I knew that the software side of the project was viable, and decided to put my effort into hardware design instead.

    I made a homebrew Arduino Uno on a breadboard, knowing that this would be the basis of the final PCB. This is simpler than it sounds - you just yoink the big chip out of an Uno, put it on a breadboard, add a crystal and a couple of capacitors and hook up 5V and ground. Doing this takes the cost of the "Arduino" part of the project down to about £4.

    Next I added buttons, potentiometers, and headphone socket. I tested the circuit with a 5V power supply, and it worked! But then I started thinking about battery power, which was something of a rabbit hole. The breadboard Arduino needs a fairly precise 5V power source. The simple, cheap option would be a linear regulator, but these waste a lot of energy and require 7V or more to work properly. This would mean I could either power DrumKid with a 9V battery (which would be dead very quickly) or 6 AA/AAA batteries, which is a silly number of batteries for such a simple device.

    I was looking for a voltage regulator chip which was cheap, efficient, easy to solder (i.e. through-hole), and which wouldn't require too many batteries. Eventually, I stumbled onto the MAX756 chip, a step-up chip which could happily output 5V from two AAA batteries. It cost £4, which is about ten times more than a linear regulator, but the rest of the project was working out pretty cheap so I decided it was worth it.

    After a frustrating few hours of misunderstanding the MAX756's datasheet, I finally got a stable 5V out of it. I hooked it up to the rest of the DrumKid test circuit on the breadboard, and had a moment of simultaneous excitement and frustration. On the one hand, I was successfully running DrumKid from two AAA batteries, using only about £10 of components in total. On the other hand, there was a weird, high, badly-tuned-radio noise that hadn't been present when I used a "proper" 5V power supply.

    At this point, perhaps stupidly, my optimism took over. While trying to get the MAX756 to work, I had found several people mentioning that it was very sensitive and wouldn't work properly on a breadboard. Someone who attempted a breadboard circuit with a MAX756 was derided on Stack Exchange for his "long loops of jumper wire", which were not only present in my circuit, but which caused the weird noise to change when I touched them. I decided that, in the absence of a more sensible plan, I would push on and design the PCB, in the hope that when I added the components, the noise would be magically gone. And that's where I've got to so far...

    Next up: PCB design, ordering/testing the PCB, and (if all goes well) designing a case.