2 days ago •
I showed my latest laser-cut plywood prototypes to a carpenter friend of mine, since I wasn't sure how to darken the wood to fit the aesthetic I was aiming for. After exploring a few options with him, I decided that using wood is perhaps more trouble than it's worth at this stage. While I would prefer to limit the amount of plastic I use, for environmental reasons, I think that perhaps it's justified in this case: it will probably be more hard-wearing, and I'm not using a huge quantity. Since I will be making DrumKid in relatively small batches myself, rather than mass-producing it, I can always re-evaluate this decision in the future.
With this decision made, I've been using my (not very advanced) image-editing skills to try and get an idea of what the first batch of units should look like. I can independently vary the following:
- PCB (top panel) colour
- Small front plastic laser-cut panel colour
- Large rear plastic laser-cut panel colour
- LED colour
I already know what an all-black design with white LEDs looks like:
I'm pretty pleased with the monochrome design. It looks slicker than I imagined. However, the black solder mask actually looks slightly grey in real life, and the colouring has been slightly inconsistent between batches (the previous, unsuccessful PCB design was also ordered in black, but came out much darker). Also, my preference has always been for bright, even garish colours, and I'd like to include this part of my personality in the final design, if possible. With this in mind, I attempted to simulate a few different colour combinations.
First, I decided to try some bold, single-colour designs. Red, green, and blue are all available solder mask colours, so I wanted to see what it would look like to match the laser-cut parts and LED colours to the solder mask:
I quite like all three of these, but with a mild preference for red. I've also had trouble finding bright, pure-green LEDs in the past (they often look more yellow-green or fluorescent yellow), and I also worry that a green solder mask would look less stylish than another colour, since green is the traditional, "default" colour for circuit boards.
My next idea was inspired by my favourite Lego theme: M-Tron. For the unfamiliar, M-Tron was a successor to the classic Lego space theme, with a bold colour scheme of red, white, black, and fluorescent yellow (specifically transparent fluorescent yellow). Here's an example:
And here's my M-Tron-inspired DrumKid mock-up:
I really like this colour combination. I could even use transparent fluorescent yellow plastic for the rear panel, showing the circuitry and giving the characteristic edge-glow effect of laser-cut coloured transparent plastic. Sadly, I can't really do the same with the front plastic section, because it would show the soldered leads of the components, which (in my opinion) are a lot less attractive than the components themselves.
I mocked up one other design, inspired by chunky Fisher Price tape recorders - I rather like the idea of using a "toy" aesthetic, because DrumKid fits into a category of toy-like electronic instruments that have become popular in the last few years (Teenage Engineering being the foremost proponents of this style). Here are a couple of images of Fisher Price tape recorders that inspired me:
And here's my "toy" DrumKid design:
In the UK, we have a brand of savoury spread called Marmite, whose slogan is "you either love it or you hate it", the idea being that its taste is so strong that you can't have a neutral opinion of it (for the record, I love it). The idea is pervasive enough that "Marmite" has entered the dictionary as a word to describe something inherently polarising. I feel like my colourful ideas are, perhaps, Marmite designs, and I'm torn about whether this is a good thing. I certainly don't want to create something that looks dull, but I'm also aware that the Hackaday Prize website contains some valuable advice from Brian Benchoff: "creating for more than yourself is a necessary part of this year's Hackaday Prize". Am I failing to do that if I choose one of my garish colour schemes? Or is it clever to make your product stand out, especially when the best "marketing" for musical instruments is when people notice a band using your instrument on stage?
In the future, I hope to offer a choice of colours when selling DrumKid - there could be a drop-down menu with the option to design your own colour scheme. For now though, I'm going to run my ideas past some of my more stylish, fashion-conscious friends before I make my final decision. The black design strikes me as dull, but the multi-coloured designs might be a step too far. Perhaps the all-red design is the answer.
4 days ago •
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.
5 days ago •
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.
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.
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.
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
09/11/2019 at 07:36 •
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
08/22/2019 at 14:00 •
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.
08/15/2019 at 14:08 •
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:
- chance (likelihood of random drum hits being added)
- zoom (whether short notes are affected by the randomness, or just long ones)
- midpoint (the average velocity of the random hits)
- range (the range of random velocities generated)
- pitch (the playback speed of the sample - can now also play samples in reverse!)
- bit crush (crunchy digital distortion)
- crop (trims the samples for a staccato effect)
- glitch (deliberately overloads the processor for weird noises)
- slop (random quantize - moves a hit forwards or back by a random amount of time)
- swing (transitions between straight and swing/shuffle rhythm)
- delay time
- delay mix (how many echoes, basically)
- beat (choose from a selection of preset beats)
- tempo (can also be set by tapping a button)
- time signature
- drift (gradually alters various parameters over time automatically)
- drop (choose which samples to mute)
- drone mod (how much to multiply the drum audio by the drone audio)
- drone mix (how much raw drone to include in the mix)
- 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:
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.
08/03/2019 at 10:43 •
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 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!
07/31/2019 at 15:43 •
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.
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.
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!
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.
07/12/2019 at 08:34 •
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.
06/24/2019 at 10:04 •
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.
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.