Close
0%
0%

DrumKid: aleatoric drum machine

A lo-fi digital drum machine which uses randomness to create unpredictable beats. Runs on Arduino, with audio provided by the Mozzi library.

Similar projects worth following
DrumKid is an "aleatoric" drum machine, meaning it uses random numbers to determine the rhythm and sound of a drum beat. It comes in a handheld, battery-powered unit, designed for live performance.Check out the video here: https://www.youtube.com/watch?v=PbklWwytfTM

Drum machine are ubiquitous in modern music, but playing them live presents a challenge. When playing electronic rhythms live, whether using a drum machine or a laptop, it can often appear that a musician is simply pressing "play" on a backing track, removing much of the perceived spontaneity of a live performance.

My drum machine, DrumKid, aims to tackle this problem by using a variety of controls to alter a drumbeat live, using randomly generated drum hits which augment the original beat. Rather than being designed as a pre-programmed backing instrument, DrumKid aims to be a playable instrument in its own right, with continuously adjustable controls that work well in a live setting. My intention was to create an engaging, interactive device that, like any musical instrument, can be mastered over time with practice.

DrumKid has the following features:

  • 4 real-time control knobs
  • 20 controllable parameters
  • Save/load function
  • Tap tempo
  • 3.5mm line/headphone output
  • Lo-fi mono 8-bit sound
  • Powered by 3xAA batteries

DrumKid is an open-source, hackable product based around an ATmega328 chip, as found in an Arduino Uno. The final product features a minimalist design consisting of a single PCB with buttons, knobs, and LEDs mounted on one side, and all other components mounted on the other side. Two laser-cut sections are used to protect the electronics.

I now have a fully working prototype of DrumKid, and I am happy with the audio quality, playability, aesthetics, durability, reliability, and battery life. I am planning to make a small, initial batch of DrumKid units in September to distribute to musicians for testing. After any necessary updates to the PCB design and/or firmware, I hope to build a larger batch of units and launch DrumKid for sale around November/December 2019.

DrumKid can also be constructed as a breadboard/stripboard project using an Arduino Uno - see the build instructions for details.

All necessary files can be found on this page and/or the DrumKid GitHub repository.

drumkid laser parts.dxf

DXF file for the two laser-cut parts of DrumKid. Designed to be cut from 3mm acrylic or plywood. Adjust the drawing for your laser cutter - text should be engraved, all other lines should be cut.

AutoCAD DXF - 28.72 kB - 08/22/2019 at 09:49

Download

drumkid breadboard.png

Illustration (in Fritzing) showing how the breadboard version of DrumKid is assembled - refer to breadboard schematic for capacitor values and clearer wiring

Portable Network Graphics (PNG) - 448.21 kB - 08/22/2019 at 09:45

Preview
Download

drumkid breadboard_schem.png

Schematic for the breadboard version of DrumKid

Portable Network Graphics (PNG) - 182.34 kB - 08/22/2019 at 09:45

Preview
Download

drumkid bom.csv

Bill of materials for DrumKid PCB

Comma-Separated Values - 1.89 kB - 08/22/2019 at 09:45

Download

drumkid schematic.pdf

Schematic for the DrumKid PCB

Adobe Portable Document Format - 68.08 kB - 08/22/2019 at 09:32

Preview
Download

View all 6 files

  • The Problem With Kids

    Matt Bradshaw2 days ago 0 comments

    I did a bit of accidental user testing recently, which has caused me to redesign part of the circuit. I met up with my cousin and his kids, who are keen musicians, so I decided to show them a prototype of DrumKid. I gave the headphones to Kid A and turned on the power. "I can hear it making noise already!" he exclaimed, before I had even started a drumbeat, and I realised instantly that I had a problem.

    As I explained in earlier project logs, using an Arduino to generate audio requires using PWM (pulse width modulation), which basically means turning one of the pins on and off very quickly to produce an audio wave. The frequency at which you turn this pin on and off must be above the human range of hearing, otherwise you will notice an unpleasant noise at this frequency.

    The library I am using to produce audio is called Mozzi, and it has a few different modes. It can use a carrier frequency of 32kHz, which is above the human range of hearing, but this requires more processing time, and wouldn't allow me to run all of DrumKid's functions. Instead, I use a more basic mode with a carrier frequency of 16kHz. This frequency is pretty much above my hearing range (I'm 34), but just about within my partner's hearing range (she's 28), so I did realise early-ish in the design process (when I showed her a prototype) that I would have to add a filter to the circuit to get rid of this noise.

    I spent quite a while researching filters, and designed a second-order low-pass filter which seemed to do the job... until I showed DrumKid to a child for the first time. It turned out that I hadn't done a good enough job of filtering the signal for people with a really good hearing range (i.e. young people), so I decided to redesign my filter, this time using a bit more science.

    I used an audio editing program called Goldwave to analyse the performance of different filters. The 16kHz spike was clear to see. I tried a few different designs, and ended up settling on a twin-T notch filter (a variation of the one recommended on the Mozzi website, which I should definitely have used to start with!). The design was tricky to get right because I was trying to satisfy several competing criteria:

    • Reduce noise to an acceptable level for people who can hear it
    • Don't filter out the "good" frequencies too much
    • Use commonly available resistor and capacitor values
    • Don't attenuate the signal too much

    I'm much happier with the signal now - it sounds indistinguishable from the previous circuit, but analysis in Goldwave shows that the carrier signal noise is much reduced. I will add a paragraph in the manual to explain the carrier signal, because it would be a good idea to do further filtering in software if you were going to record a track with DrumKid, especially if you were to pitch-shift it downwards. However, I think the improved filter circuit means that the output signal is now acceptable for the final product.

  • Multiplying

    Matt Bradshaw4 days ago 0 comments

    Up until today, I've only made one successful, working DrumKid unit, which isn't much good for something I want to sell. While it's almost certain that there will be another PCB revision, I decided to make several identical DrumKid units using the current PCB version, for a few reasons:

    • I want to do some user-testing with local musicians
    • I want to see how long it takes to build each unit
    • I want to check that the design is stable, and the first unit wasn't a fluke
    • I had several of the most recent PCBs available anyway

    I checked my stock of components, and ordered the ones I was running out of. Having realised that finding each individual value of resistor and capacitor was a bottleneck when building the first unit, I organised all my components into DrumKid-specific project boxes with dividers, to speed up the build.

    Sorting the components in advance made assembly a lot easier

    I also contacted a local business who have a laser cutter, and they were happy to help me with an initial small run, as well as bigger orders in the future. I decided to cut the laser parts from plywood, since my preference is to avoid using plastic where possible, although we also made one set using some scrap transparent orange acrylic, just to try a different look.

    The view through the top of the laser cutter
    Testing a transparent orange plastic enclosure - it looks cool but I'm not convinced

    I timed the assembly process, during which I built three new DrumKid units from scratch. This involved positioning and soldering the components, mounting the battery box, uploading the firmware (Arduino sketch) to a blank chip, testing each function, and assembling the laser-cut outer enclosure.

    In total, it took just under three hours to build three units, which obviously translates to about an hour per unit. This doesn't include things like time spent ordering and sorting components, or time spent packaging a finished unit, but I might also be able to speed up assembly with practice, and by assembling larger batches at once. Overall, an hour per unit feels like a reasonable ballpark figure to estimate for the next run of units. I also switched the previous unit to have the same laser parts as the new units, just for consistency.

    I was really happy with how the units turned out. They all worked first time, and all look identical. I want to stain the wood a darker colour for aesthetic reasons - I don't think the light-coloured plywood looks very nice with the black front panel. This would slightly increase the cost and assembly time, but not by much, especially if I could stain a large number of laser parts at once.

    Soldering in progress
    Very satisfying to see four, identical, working DrumKids...
    ...but need to stain the wood to improve the aesthetics

    Here are a few thoughts after successfully multiplying DrumKid:

    • DrumKid is a viable product, even at a fairly low price point
    • The mounting holes for the potentiometer are a fraction of a millimetre too small, which adds time (and mechanical stress!) to each unit while I try and wriggle them into place - I should fix this on the next PCB
    • I'm still not 100% sure about the materials and colour scheme for the final version. I might play around in an image editor to try some different colour combinations
    • It would be good to leave a solid patch of white silkscreen on the underside of the PCB to write the serial number of future DrumKids

    And here are some of my immediate next steps in the project:

    • Stain the wooden parts in these four units to see if that makes them look better
    • Shoot footage for the Hackaday Prize final video
    • Give three units to local musicians for feedback
    • Decide on colour scheme and whether to have a fully enclosed design (vs current open-sided design)
    • Design next iteration of the PCB

  • Hackaday Prize Finalist!

    Matt Bradshaw09/11/2019 at 07:36 0 comments

    Rather excitingly, DrumKid has made it to the finals of the Hackaday Prize 2019! I got through to the semi-finals last year with my digital modular synthesizer, PolyMod, but really struggled to meet the criteria for the final - I was still using stripboard for all my projects at the time, and I didn't even know what a schematic was (I instead submitted a messy pencil sketch of a sort of flowchart).

    In the past year, I've put a lot of effort into moving on from stripboard, wood, drills, and saws. I've acquired a 3D printer, learned to use KiCAD, designed and ordered my first PCBs, and generally moved a lot further towards my goal of designing something that looks professional (or at least less amateur). I've also belatedly learned what a schematic is, and produced some!

    I'm really happy with DrumKid's progress so far, and luckily I've already fulfilled a lot of the criteria for the final round, but I'd still like to put in a big push to improve the project by October 1st, the deadline for the finals. I can't go into full production mode by then, but I can lay a lot of the groundwork. Here's my September to-do list:

    • Source enough components to make a small initial run of DrumKid units for testing
    • Find a local company with a laser cutter
    • Explore possibility of moving to an enclosed case design, rather than the current open-sided, standoff-based design (this is based on early user feedback). I'm hoping to use recycled wood for this to reduce environmental impact
    • Add a couple of minor features to the code - there are a still two free slots for controllable parameters, I'd like DrumKid to automatically load the last saved patch when powered on, and I'm also anticipating a few tweaks based on user feedback
    • Research packaging
    • Do a full cost analysis to determine how much I should sell the finished unit for - I've already got a pretty solid idea of this but I'd like to go over my numbers in more detail
    • Make a final decision on aesthetics - I can easily vary the PCB colour, the LED colour, the laser-cut section colour and the laser-cut section material (plastic or wood)
    • Design and order a fifth revision of the PCB
    • Make an improved video for the final round

  • Video Demo

    Matt Bradshaw08/22/2019 at 14:00 0 comments

    Here we are! DrumKid is finished for now - it sounds the way I hoped it would, it seems to be nice and stable, and the battery life appears to be great. I've uploaded all the latest schematics, PCB files, etc to Hackaday and written some build instructions for anyone who wants to make a breadboard version.

    Here's an in-depth video I made to demonstrate the project:

    The theme of this year's Hackaday Prize is "design for manufacture", which was good timing for me because I was already hoping to release my first commercial instrument in 2019. I decided that DrumKid would be a good project to enter for the prize, and I have been trying to make sure it hits the prize criteria:

    Is this a unique solution to a particular challenge facing the world today?

    I believe that DrumKid is a unique solution to the (first-world!) problem of drum machines being too static and inexpressive. I have been to many gigs where the approach to electronic drums is to just press "go", and either leave them looping or playing through a preset sequence, which is no better than playing to a backing track. There are some interesting approaches to solving this problem using expensive, complex, modular synthesizers, which also often employ random numbers to influence beat parameters, but I haven't seen anyone attempt to tackle this challenge with a similar approach to DrumKid, and certainly not in a compact, inexpensive unit.

    How thoroughly documented were the design process & design decisions?

    I have tried to give a full account of the project in the build logs, from its genesis as an iPad-based drum machine app for my band, to a breadboard prototype, to a 3D-printed prototype, and finally to the form it is in now. I've gone through four iterations of the PCB, with each version's successes and limitations described in the build logs. I've also committed regularly to the project's GitHub repository, so there is a thorough and accurate record of the design process (especially the evolution of the code) available to see publicly there.

    How ready is this design be taken to market?

    I estimate that DrumKid is about three months from being available to buy on Tindie. While I could start selling units immediately, since the current version is stable and working nicely, I would like to build a small initial run of units for musicians in my network to test and give me feedback on. Depending on what feedback they have, I should then have time to tweak the firmware code or, if necessary, produce another revision of the PCB before starting to make a larger batch of DrumKid units by November 2019.

    How complete is the project?

    In terms of my aim to build a working aleatoric drum machine that I can use myself, the project can be considered 100% complete. In terms of creating a drum machine that I can sell to the public, it's harder to say, but I feel like I'm at around 90% - I've made an effort to ensure that the most recent version is built using easy-to-source components and can be assembled quickly, so I've got my fingers crossed that the final push from having one finished unit to having 10 or 100 will be linear rather than exponential. I'll continue to document my progress here.

  • Code Nearly Done + Audio Sample

    Matt Bradshaw08/15/2019 at 14:08 0 comments

    I've spent most of this week working on DrumKid's code. There are 20 possible parameters to control using the buttons and knobs, so this week's task was to work out which 20 features would make it into the final design, and write any necessary code to implement those features. I'm now almost certain that the 20 controllable parameters will be:

    1. chance (likelihood of random drum hits being added)
    2. zoom (whether short notes are affected by the randomness, or just long ones)
    3. midpoint (the average velocity of the random hits)
    4. range (the range of random velocities generated)
    5. pitch (the playback speed of the sample - can now also play samples in reverse!)
    6. bit crush (crunchy digital distortion)
    7. crop (trims the samples for a staccato effect)
    8. glitch (deliberately overloads the processor for weird noises)
    9. slop (random quantize - moves a hit forwards or back by a random amount of time)
    10. swing (transitions between straight and swing/shuffle rhythm)
    11. delay time
    12. delay mix (how many echoes, basically)
    13. beat (choose from a selection of preset beats)
    14. tempo (can also be set by tapping a button)
    15. time signature
    16. drift (gradually alters various parameters over time automatically)
    17. drop (choose which samples to mute)
    18. drone mod (how much to multiply the drum audio by the drone audio)
    19. drone mix (how much raw drone to include in the mix)
    20. drone pitch

    It was a process of trial and error to reach this list of features. Some ideas (such as switching between different sets of samples) were ruled out because there wasn't enough storage or memory. Other ideas took a while to get right - I was really keen to have the ability to play samples in reverse, but I had to clone the Mozzi library and edit some of its code to enable this. I also had to clone and edit the ArduinoTapTempo library to make it do what I wanted. I'm aiming to make pull requests for the features I added to these libraries once I'm done with DrumKid.

    As well as adding these 20 controllable parameters, I added a number of other features, such as the ability to save and load patches from the ATmega's EEPROM. I also spent quite a while optimising the code, and working out how to store as little as possible in the ATmega's (tiny) RAM. As things stand, the program storage space is at 93%, while the dynamic memory is 87% full from global variables alone (enough to trigger a warning in the IDE, but I've done plenty of checks to make sure it's fine).

    So, overall, the technical side of things is good, but more importantly, DrumKid is sounding good! I recorded an audio demo today to try and show off most of its functions. Have a listen here:

    https://soundcloud.com/mattbradshaw/drumkid-test-audio-2

    Just a couple of tiny tweaks to the code now, and then I can put the breadboard's chip into the proper prototype unit and record a video demo.

  • Explaining the Randomness

    Matt Bradshaw08/03/2019 at 10:43 0 comments

    So far, almost all my build logs for this project have been about technical challenges, design choices, etc - there has been very little about the most interesting aspect of this drum machine: the way that randomness creates a beat. Now that I'm happy with the basic design and am well into the coding section of the project, this seems like a good time to explain the algorithm (if that's the right word?) behind DrumKid.

    DrumKid starts off as a pretty regular drum machine. It begins with a basic 16-step drum pattern, e.g. "kick hat hat hat snare hat hat kick kick hat kick hat snare hat hat hat" (it can play multiple sounds at once, but that's much harder to write in a sentence!). This basic pattern is then modified using random numbers in the following way:

    Imagine that for each type of drum (kick, snare, hat, etc), and for each step in the sequence, you roll a dice. If you roll a six, a drum hit is added to the sequence. So, as well as the original pattern, about a sixth of the steps (for each type of drum) that would have been empty now have drum hits. These dice rolls will be different every time, creating an unpredictable beat.

    If we want the beat to be more unpredictable, we could lower the threshold of when we add an extra hit - say, when we roll a six or a five. This threshold effectively controls how much randomness we allow into the beat, and is controlled by a knob on the drum machine (obviously with a much bigger range than the one to six of a dice!). Turning the knob to zero will mean that only the original pattern is played, while turning it up to maximum will mean that every drum is triggered on every step. This parameter is called chance.

    This sketch helped me figure out how to code DrumKid's aleatoric algorithm, but is probably deeply unhelpful as an explanatory diagram

    This is an interesting start, but it sounds much nicer when we also vary the volume/velocity of each drum hit. Let's imagine that every time the first dice has determined that there will be an extra hit, we will also roll a second dice to determine the velocity, with a roll of one creating a very quiet hit, and six creating a very loud hit. This will sound interesting, but a little bit wild - we want a way to tame this randomness.

    We can define a minimum and maximum value for these random velocities, so that, for instance, all of the extra hits are between 30% and 50% volume. This allows the original pattern to remain discernible, while adding a sort of sub-groove to the beat. Alternatively, you could put the minimum at 10% and the maximum at 90%, creating a much busier feel. After a bit of experimenting, it turns out that the most intuitive, live-performance-friendly way to control these parameters is not with "min velocity" and "max velocity" knobs, but with one knob to determine the midpoint the random velocities, and one knob to control the range. This means you can create a drum fill simply by turning up the midpoint knob.

    Manipulating these three knobs, chance, midpoint, and range, gives a lot of expressive control over a drumbeat, and these will be the main default controls on DrumKid. By pressing different buttons, it will be possible to switch the knobs to other functions, including audio effects like pitch shift, bit-crush, etc, and there may be other more obscure randomness-based parameters (perhaps an inverse of the process described here, which removes hits rather than adding them), but these three controls are the heart and soul of DrumKid, and provide its signature sound.

    Coding is going well, so hopefully there will be an audio/video demo soon!

  • Prototype Version 4 - Success!

    Matt Bradshaw07/31/2019 at 15:43 0 comments

    So, the previous prototype looked cool but a routing error meant that it was completely non-functional. Unperturbed, I rerouted the design in KiCAD, fixed a couple of other errors I'd noticed, and ordered a new run of five PCB's, which arrived last week. I soldered everything in place, plugged in the battery pack, and... disappointment. The LEDs were flickering dimly, and a drumbeat was barely discernible through white noise in the headphones. I was frustrated, and busy with other work, so I put the barely-functional prototype to one side for a few days.

    Spot the difference - version 3 on the left, version 4 on the right

    Yesterday, with a free afternoon ahead of me, I waded back into the problem. My first thought was that the batteries weren't powerful enough, perhaps due to some bad soldering that was causing the circuit to leak power somehow, but I tried a few different power sources and the results were the same. I tried a simpler Arduino sketch, and managed to get the LEDs working at full brightness, which led(!) me to realise that I'd done something stupid in the original sketch. I corrected my original mistake and moved onto the audio problem.

    The audio was noisy, inconsistent, and had an annoying high-frequency buzz. Cunningly, I had included breakout pins in the PCB design, which meant I was able to easily intercept the raw, low-voltage audio output before the amplifier chip (LM386) and have a listen. I fed it through what should have been an identical amplifier circuit on the breadboard prototype, and the sound was much nicer, albeit not perfect, so I painstakingly double-checked whether my KiCAD schematic accurately reflected my breadboard. It did not! I had forgotten to ground pin 4 of the LM386. I briefly thought "oh no, I guess I'm ordering another PCB" before realising that this mistake could be fixed by soldering a small wire from pin 2 to pin 4. Obviously not a long-term solution, but fine for a prototype.

    Quick and dirty hack to ground pin 4 of the LM386

    Suddenly there was progress. The volume control went from near-silent to super-loud, with no white noise, but there was still a high-frequency buzz. I showed the almost-working drum machine to my always-supportive partner, secretly hoping she might not even notice the buzz, but she pulled a face and said it sounded horrible. This problem turned out to be super-easy to fix, though - I just added a single decoupling capacitor (I had left optional holes for several on the PCB layout), and everything was perfect!

    First assembly with laser-cut pieces

    And not only was the PCB working, but a very generous Twitter-friend had laser-cut the two parts I needed to complete the prototype, and sent them to me in the post. This means that I'm now at a very exciting stage:

    • The PCB works, with only one tiny extra wire needed to account for a minor error in the design
    • The laser-cut parts look and feel great, and I'm happy with the overall aesthetics of the drum machine
    • The Arduino sketch is producing nice, clean audio via the Mozzi library
    • The PCB now matches the breadboard design pretty much exactly, which means I can work on the code using an Arduino and a breadboard, safe in the knowledge that it will work on the PCB once I'm happy with the code

    I've now got a couple of weeks to focus on the code before the Hackaday Prize deadline, making sure the drum machine is intuitive, fun, and (most importantly) musically interesting.

    Two drum machines, identical in function but not form - this will be my prototyping setup while I work on the code

  • Prototype Version 3

    Matt Bradshaw07/12/2019 at 08:34 0 comments

    Happy with recent progress! After deciding to go for a more simple, bare-bones design, I designed a new PCB which ran off 3 AA batteries instead of 2, eliminating the need for voltage regulation. I also made the decision for the top surface of the PCB to be the actual front of the instrument, eliminating the need for a traditional case. Long story short, the PCB arrived and this is approximately what it looks like when assembled, with a few caveats to be discussed further down:

    You can see that the design consists of a top and bottom layer, separated by standoffs, as well as an extra "palm rest" piece on the top layer, to cover ugly/sensitive electronics. The main circuitry is on the underside of the top PCB - the "palm rest" piece just hides the solder. There are now six buttons and four knobs on top to control the instrument, plus a volume knob. I'm really pleased with the look and feel of the instrument, but there are a number of ways in which the final version will differ from this mock-up:

    • The potentiometers will be slightly shorter and knurled for better ergonomics
    • The standoffs and machine screws will be metal for better durability
    • The battery holder, which is mounted on the underside of the PCB, will be secured in place with machine screws and dome nuts, for better aesthetics than the current temporary nut
    • In this photo, the top "palm rest" cover is 3D printed, while the bottom, protective layer of the case is actually just a spare, unpopulated PCB - both these pieces will likely end up as laser-cut plywood or acrylic

    There is also one other key way in which this prototype can be improved: it doesn't actually work! I'm embarrassed to say that I was rushing to finish the PCB design before heading to Glastonbury music festival with some friends, and ended making a silly mistake which rendered the entire board unusable. I am very keen for this design to be "hackable", so I have added breakout connections for all the main Arduino pins (5V, ground, 14 digital pins, 6 analogue pins), but I was struggling slightly for space and, as far as I can tell from reviewing the KiCAD files, I must have attempted to move the breakout pins halfway through routing the board. In doing so, I created a short circuit which I only noticed when testing an assembled board. Here's what I did:

    All I had to do was click the "run DRC test" button, and this mistake would have been glaringly obvious, but by this point it was midnight and my mind was focused on packing for the festival. Never mind! It was a good lesson, and there were a couple of other minor issues with the board which I noticed anyway (mounting holes in the wrong place, poor layout choices, etc), so I've created a minor revision of the board and ordered another small run of 5 PCBs from China. Fingers crossed! In the meantime I can keep working on the code/firmware using my breadboard/Arduino circuit.

  • Overcoming Fatigue

    Matt Bradshaw06/24/2019 at 10:04 5 comments

    I've hit a bit of a slump with this project so I'm writing a log to try and clarify my thoughts.

    I like to think that I'm not the only maker whose shelves are littered with half-finished projects. Initial ideas are exciting, and that excitement often propels me as far as an initial proof-of-concept build, but then the grind of iterating the design kicks in and that often causes me to give up. "DrumKid" has already surpassed the vast majority of my previous projects, in that I've created several breadboard versions, a stripboard version, and two PCB versions, as well as a 3D-printed case. This is something to be proud of, and yet, paying-the-bills work has pushed DrumKid development off my immediate list of priorities, and the Hackaday Prize deadline is steadily moving closer. What to do?

    At the start of this project, I promised myself I would take the simplest route where possible. Getting bogged down with power management, amplification, and case design has taken me away from the super-simple design I was imagining. It's time to be brutal and come up with a simple, bare-bones product. My mentoring session gave me some really good tips about how to simplify the circuit design, and now I think I have a good plan for simplifying the case design - by not building one.

    A friend bought me a Pocket Operator drum machine for Christmas. This instrument is made by Teenage Engineering, who seem to specialise in stripped-down design. The Pocket Operator is simply a single PCB, with buttons, knobs, and a display on the front, and batteries on the back. All the other components appear to be hidden under the display.

    Pocket Operator drum machine by Teenage Engineering - possible inspiration for my next prototype

    If I can design DrumKid in a similar way, I think that would solve a lot of my problems. Since I'm using fairly chunky through-hole components, I might need to use two PCBs (separated by stand-offs), one for the interactive components (buttons, knobs, LEDs) and one for the "other stuff". I might also need some sort of covering to prevent fingers touching sensitive circuitry.

    I like the aesthetic of the Pocket Operator, too - it's simple and utilitarian, but playful at the same time. I'm going to do a few sketches and see how practical it is to make a DrumKid prototype in a similar style.

  • Mentoring Session

    Matt Bradshaw05/24/2019 at 09:18 0 comments

    I had a really useful mentoring session with Mitch AltmanMajenta Strongheart and two other Hackaday Prize entrants on Thursday. It was really interesting to see how the other entrants approached their projects, and I learnt a lot from talking to Mitch about the development process.

    Coincidentally, Mitch has previously built an Arduino-based synth with a lot of similarities to my project. I looked at his schematics before the session and noticed a few things:

    • Both our projects used an Atmega328 to generate audio
    • Both projects used an LM386 to amplify the audio
    • While my project uses a relatively expensive chip to boost the voltage of 2 AAA batteries, Mitch's synth runs directly from 3 AA batteries

    This comparison was really interesting and useful - it told me that my approach to the circuit was fairly uncontroversial, but it also suggested that I could do away with the most problematic element of my design, the expensive and noise-producing voltage boost chip. I hadn't previously realised that the Atmega328 could run happily on less than 5V (forum posts had suggested otherwise), so it was very gratifying to hear Mitch confirm that it works fine on 4.5V. Straight after the mentoring session, I hooked my breadboard circuit up to three AAA batteries and was excited to realise that it worked fine, with barely any noise.

    A few other things I took away from the mentoring session:

    • My problems with making mistakes during PCB design are normal, and it's an accepted part of the development process to just hack the incorrect design and then incorporate the fix into the next version
    • It might be worth investigating Seeed Studio in future for board assembly (in case me hand-soldering the boards becomes a bottleneck when producing larger quantities)
    • CNC routing could be an option for the case if laser-cutting isn't suitable

    Overall, really happy that I was able to take part in this mentoring group - it helped me with both big-picture thinking and with the specifics of my project.

View all 19 project logs

  • 1
    Source components

    The simplest way to get a version of DrumKid working (apart from buying one when it's released!) is to build the breadboard circuit using an Arduino. The components are mainly pretty standard: you'll need a breadboard, jumper wires, an Arduino Uno, tactile buttons, LEDs, 10k potentiometers (linear), an LM386 amplifier chip, and a selection of capacitors and resistors. You'll also need some sort of breadboard-compatible headphone socket - I used a 3.5mm socket with screw terminals which is designed for prototyping like this.

    3.5mm stereo socket (wired as mono) with screw terminals to connect to the breadboard

    I've squeezed everything onto a single breadboard with small buttons and tightly spaced potentiometers, but you might want to consider sprawling over two breadboards, which would allow you to use bigger buttons, making for a more ergonomic playing experience. Using a second breadboard might also give you space to use a breadboard-friendly Arduino variant, keeping the whole project a bit neater, although I haven't tested this.

  • 2
    Build breadboard circuit

    Build the breadboard circuit shown below. Refer to the schematic for capacitor values. There are six push buttons which use the Arduino's internal pull-up resistors, five LEDs with current-limiting resistors, and four potentiometers connected to the Arduino's analog inputs. All these parts of the circuit are fairly standard, and found in lots of basic Arduino examples.

    The more complex part of the circuit is found on the right of the breadboard - this takes the audio output from pin 9 of the Arduino and filters it, before amplifying it. The raw audio output is a PWM output which has quite a lot of unwanted noise (the carrier signal), so I've added a 2nd-order RC filter to clean it up. In doing so, I've removed quite a lot of the higher frequencies, which I'm happy with because of the lo-fi sound I'm aiming for, but if you want to keep more of the high frequencies (at the expense of a noisier signal), you can try different resistor and capacitor values. The LM386 part of the circuit then amplifies the signal. There are many ways to wire an LM386, so feel free to use a different circuit for this if you'd prefer.

    If you just want to play around with DrumKid and aren't too worried about audio quality, you can just connect your headphone socket straight to pin 9 and ground, and omit the the LM386 circuit, filter circuit, and volume control.

  • 3
    Upload Arduino code

    Download the DrumKid repository from https://github.com/mattybrad/drumkid and use the Arduino IDE (software) to open the Arduino sketch found at drumkid/arduino/drumkid/drumkid.ino

    The code relies on several external libraries, so you will either need to install them using the Arduino library manager or from a zip file. Any libraries not available through the library manager will be noted in the code.

    Make sure that the DEBUGGING constant is set to "false", and BREADBOARD is set to "true", then upload the sketch to the Arduino. If all goes well, you should see all five LEDs flash rapidly, after which you can play your breadboard drum machine.

View all 5 instructions

Enjoy this project?

Share

Discussions

Dan Maloney wrote 3 days ago point

Glad to see you're making progress on this. And great documentation, BTW!

  Are you sure? yes | no

Matt Bradshaw wrote 3 days ago point

Thanks, Dan! Yeah, I'm really happy with how the first batch turned out. Can't wait to see how musicians use them.

  Are you sure? yes | no

Ken Yap wrote 08/01/2019 at 08:35 point

Nice going, looks like the break did you good. 👍

  Are you sure? yes | no

Matt Bradshaw wrote 08/01/2019 at 08:42 point

Thanks :) Yeah, it's going much better now!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates