a day ago •
After some forensic investigation, I have identified (and, I think, solved) my two remaining issues with the V5 PCB, but I would be grateful for any feedback about my MIDI solution.
The sound is too bright (too much carrier frequency remaining in audio output)
This one was pretty dumb. I'm using the twin-T notch filter design from the Mozzi website but I made a mistake transcribing this circuit into my schematic, meaning that two of the capacitors have switched places.
I (clumsily) desoldered C3 and C7 and swapped them over. The audio output now sounds fine.
Connecting a MIDI input results in audible tones and clicks through the audio output.
Something to do with grounding or decoupling? It feels as though the MIDI input's optoisolator (a 6N138) is perhaps being a bit heavy-handed with its use of the available electricity (please don't disqualify me from the site for this appalling lack of understanding).
After lots of googling, I stumbled onto this seemingly similar problem and decided to whack a big (1000uF) capacitor across the 6N138's power and ground. I tried smaller values but to no avail. I suspect that adding a smaller (but still big-ish) capacitor to the LM386 and also maybe the ATmega328 might be a better solution, but I've already made a mess of the PCB! For now, the noise is virtually gone, so I'm calling that a win.
11/15/2019 at 13:10 •
The fifth iteration of the DrumKid PCB arrived from China this week, and I'm pleased to report that it pretty much works! I had changed and added quite a lot since V4, so there were always likely to be a few problems, but overall I'm pretty happy.
Assembly was made much easier by including the resistor and capacitor values on the silkscreen layer, which I didn't do in V4. However, I forgot to identify a few other components and polarities on the silkscreen layer. This isn't a big deal when I've got the KiCad files to refer to, but worth fixing on the next version, especially if I'm going to make DrumKid available as a kit.
The two main problems I ran into were related to two of the biggest changes I made. I significantly altered the low-pass filter on the audio output to try and remove more of the PWM carrier signal, but I'm not sure I've done it correctly - the audio sounds much brighter than I was expecting, and has some issues at full volume (possibly related to running off batteries rather than a 5V USB supply).
Another problem is that when a MIDI input is connected, each MIDI signal causes an audible click, or a loud tone, in the case of MIDI clock messages, which are sent very frequently. I had come across this issue on my breadboard prototype but assumed it was just due to the inadequate ground of the breadboard. I was wrong! I'm currently experimenting with a decoupling capacitor on the optoisolator to solve this problem.
Oh, and one final, stupid mistake I made: I added a power LED so that it was obvious when DrumKid was on, but somehow managed to connect both legs of the LED to ground in the layout. Clearly KiCad's "electrical rules check" doesn't check for that...
So, overall, a bit of a mixture of good and bad, but that was probably to be expected for a fairly major revision of the design. It's certainly going to delay the release (I've tried to remove mentions of a November release date from the web where possible!). I'll see what I can do to fix the issues by hacking this PCB, then design and order a minor revision ASAP.
I always knew that this project would be a learning process. I was attempting to jump from having minimal PCB design skills to releasing a reasonably complex product with a mixture of analogue and digital circuitry, so although I did initially get a bit cross at V5 for not being perfect, I'm philosophical about it - we're getting there!
11/05/2019 at 13:47 •
Have finished designing a new PCB, the fifth iteration since I started the project. I'm waiting for it to arrive from China, but here's roughly what it will look like:
The overall footprint is a little longer to make room for the MIDI ports, there's more info included on the silkscreen layer, there's an extra LED to show when the power is on, the volume and power controls are now aligned with the audio output, and there are a bunch of boring changes to the component layout on the other side. Oh, and everything is red now.
I've also ordered some black nylon knurled thumbscrews to allow the batteries to be changed without needing a screwdriver.
Meanwhile, coding continues, and I've sent a V4 prototype to Pasadena for Supercon. I won't be there, but hopefully DrumKid will!
10/14/2019 at 15:10 •
After getting lots of feedback, I'm attempting to add MIDI to DrumKid. Many people have expressed a hope that DrumKid would feature the ability to synchronise with other instruments, and I've decided that MIDI is the best way to do this, because this also gives the option of using DrumKid as a MIDI controller, thereby greatly expanding its capabilities.
(For the uninitiated, MIDI stands for "musical instrument digital interface", and is a type of serial connection which allows musical instruments to send data to each other, such as notes, timing, and other controls.)
Outputting MIDI note data from DrumKid was very easy, and instantly convinced me that MIDI was a vital feature which had been missing all along - I was suddenly able to produce a much wider variety of sounds by triggering other drum machines' samples. However, generating synchronisation data has proven much harder. The MIDI "clock" standard requires a byte of serial data to be sent 24 times per quarter note. Had I thought about this from the outset, I probably wouldn't have designed my code around an arbitrary division of 16 pulses per quarter note, because these two divisions are basically incompatible! I was able to get my Korg synth to sync up with DrumKid, but only at lower tempos, and not with any great reliability.
After several hours of trying to fudge the code, I decided it's time for a major rewrite. The code had become bloated and messy, and I was pushing right up against the RAM limit anyway. Now that I'm 90% sure that DrumKid will feature MIDI, I'm going to incorporate it properly, rather than as an afterthought.
The next GitHub update might be a pretty major one!
09/30/2019 at 15:49 •
Well, the Hackaday Prize final deadline is tomorrow, and I think I've squeezed as much progress out of DrumKid as possible in that time! I thought it would be nice to reflect on how far the project has come since it began.
- Started exploring the idea of converting my DrumKid web app into a physical project
- Got some good sounds from early breadboard prototype
- Experimented with voltage regulator chips
- Designed V1 PCB
- Assembled V1 PCB (which worked, but was too quiet and had noise issues)
- Designed and 3D-printed a case
- Decided to increase number of potentiometers
- New stripboard prototype to diagnose problems more rapidly
- Added filter circuit
- Designed V2 PCB
- Hackaday Prize mentoring session
- Rethinking the enclosure design
- Designed V3 PCB
- Assembled V3 PCB, instantly found routing issue
- Designed V4 PCB (minor revision)
- Designed and 3D-printed front and rear panels, to be laser-cut in final version
- Sourced test laser-cut pieces (success!)
- Assembled V4 PCB (success!)
- Concentrating on coding
- Added lots of features
- Made demo video
- Found local laser cutter and obtained enough pieces for three new (identical) V4 prototypes
- Did a "test run" of assembly, successfully built three new units
- Distributed DrumKids to testers
- Received feedback from testers
- Started V5 PCB design
And that takes us up to today! I'm really pleased with where I've got to, and am excited to complete the V5 PCB design over the coming days. Good luck to all the other Hackaday Prize finalists, and if anyone wants to be kept updated about DrumKid's launch later this year, please go to mattbradshawdesign.com and sign up my mailing list.
09/30/2019 at 13:43 •
Here is a selection of photos showing the inside of the current version of DrumKid.
09/30/2019 at 11:54 •
This is a brief post where I will discuss exactly how open source DrumKid is (spoiler: as open source as I was able to make it).
My aim from the start of the DrumKid project has been to create a fully open source instrument, in terms of both hardware and software. I based the design on the Arduino platform, which is itself open source, and have shared all my schematics, CAD files, parts lists, etc under the MIT licence, so it's fair to say that the hardware side of my project is fully open source, which is great.
The software side is a little more complex. My code (which is also shared under the MIT licence) relies on two external libraries. One library which I make some use of is the ArduinoTapTempo library, which also uses the MIT licence. However, my code is based heavily on the Mozzi audio library, which is shared under a Creative Commons Non-Commercial licence.
Mozzi is a clever, extensive library that somehow squeezes complex audio out of an Arduino. The creator of Mozzi has (entirely fairly) released his code under this licence so that, while other people can use it to make cool projects, he reserves the right to negotiate a share of the profits if a commercial product makes use of his work.
I reached out to Mozzi's creator while I was developing DrumKid, and we quickly came to an amicable agreement about future profits, which means that DrumKid is "good to go" from a legal standpoint. However, it does leave this project in a sort of open source limbo. All the code that I have written is fully open source, and I personally have permission to use all the code that DrumKid relies on, but if anybody other than me started making and selling DrumKids, they would be in breach of Mozzi's licence (unless, of course, they also reached an agreement with its creator).
If somebody did want to sell DrumKid clones legally, one way would be to eliminate the need for the Mozzi library by "rolling their own" - while I do make extensive use of Mozzi, I only use a small subset of its features, so it wouldn't be that difficult to write some code that performed a similar function.
Personally, I'm happy to keep using Mozzi and pay a small fee to the developer who made DrumKid possible, but I thought this was an interesting aspect of open source culture: when money starts to get involved, things do get more complex!
09/28/2019 at 17:23 •
Designing for other people is a lot harder than designing for yourself, which makes this project harder than almost all of my previous ones - the aim is to get DrumKid into the hands of as many musicians as possible, which means I actually have to listen to constructive criticism. I've tried to elicit feedback throughout the project, but this has ramped up recently as I approach my self-imposed deadline of making the first batch of finished DrumKids by November.
I've now received comments from all three musicians who are currently using the latest prototype of DrumKid, so I thought this was a good point to share the feedback I've had throughout the project and how I've adapted the design based on it (or plan to in the near future).
My main sources of feedback/criticism have been:
- Informal feedback from friends (usually when I bring the latest prototype to the pub)
- YouTube comments (I'm one of the few creators whose comments are nearly always nice)
- Hackaday (comments, chat, and mentoring session)
- E-mail (usually unsolicited but very helpful!)
- Feedback from musicians who are currently using DrumKid
Overall, spread over these various mediums, I've had a lot of helpful comments throughout the project! I thought it would be helpful to document them here, roughly in chronological order.
Source Comment Response Early feedback from friends Too much high-frequency noise Improved the filter circuit Early feedback from friends Output is too quiet (this was with the volume on max in a noisy pub - the filter was reducing the output too much) Added an amplifier chip to boost the signal Early feedback from friends The early single-knob design was too confusing and difficult to play I agreed with this comment and redesigned DrumKid to feature four knobs instead of one Email and YouTube comments DrumKid should be compatible with Eurorack synthesizers, and the different parameters should be controllable via external control voltages Creating a DrumKid Eurorack module would be a separate, complex project, but there seems to be a lot of demand for it, so I've started making notes about a potential future design, maybe using a Teensy Email and YouTube comments DrumKid should be able to synchronise its tempo with other instruments This has come up quite a lot, often enough that I'm considering adding this feature to the final design, although it might delay the release by a couple of weeks YouTube comment It would be good to be able to load custom sample sets (different kicks, snares, etc) Although it would be hard to make this part of the core, supported features of DrumKid, switching the samples is such an obvious customisation that I'd like to document a way for people to do it. This has made me realise that I should write a secondary "hackers' manual" for DrumKid to help people who want to customise their instrument Tester There should be more different styles of basic drumbeat, such as drum 'n' bass, reggae, waltz, etc I agree with this, and will spend some time adding more beats for the next version Tester The volume knob seems to be mounted backwards This is true - either the KiCad footprint is wrong or I did something stupid, but I will fix this in the next version of the PCB Tester There should be more than six slots to save beats in This is probably fair. There is plenty of space in the EEPROM to save more beats, but I wanted to keep the user interface nice and simple (six buttons, six save slots) - I'm considering increasing this to six banks of six (36 slots) Tester The loading process is unreliable and confusing I hadn't noticed this before, but I think there is a bug in the code, so I will investigate Tester The LEDs are too bright I noticed this, too, and had already planned to reduce the brightness for the next version, which should also have the benefit of increasing battery life Tester Beats in non-standard time signatures have strange emphases My previous, slightly lazy approach to non-4/4 time signatures was to simply truncate or repeat a 4/4 pattern, but this is musically bad. I should either have various versions of each beat for different time signatures or perhaps just have a greater range of preset patterns, including "good" 3/4, 5/4, and 7/4 patterns Tester For some parameters, the left position is a neutral, unchanged sound and the right position is a "crazier" sound, but sometimes it's the other way round, which is unintuitive This is a fair point. I never had a good, uniform justification for why some parameters go left-to-right and others right-to-left, so I will standardise this behaviour Tester Replacing the batteries would be difficult This is perhaps a weakness of the current design - to replace the batteries you need to undo six screws. It only takes about a minute if you have a screwdriver, but not everyone does! I'm going to see if it's possible to source some knurled thumbscrews so that the batteries can be replaced without a screwdriver Tester It's hard to start messing around with DrumKid without consulting the manual - it would be good to have the parameters written underneath the knobs This was mentioned by two different testers, so I should probably add explanatory text on the next PCB. I rather like the minimalism of the current design, but even I kept forgetting which knob controlled which parameters, so I'll try and find an aesthetically pleasing way to include this text Tester The pitch control for the drone is difficult to use I agree with this, but it's also hard to think of a better way to do it. I'll take this on board and try to come up with a better implementation Tester An LCD to display the BPM (tempo) would be really useful I agree that it would be good to see the exact current tempo. I could perhaps try and display it using the LEDs somehow, or even consider replacing the row of LEDs with a seven-segment display, but that would be quite a radical change Tester It would be good to have either stereo or multiple outputs, so that different drums could be recorded separately I think this is beyond the scope of a low-cost drum machine, but I'm considering this feature for the Eurorack version Tester It would be great if the "zoom" parameter (which controls whether the random extra hits are quarter-notes, eighth-notes, sixteenth-notes, etc) could do triplets I also found myself wanting this feature while playing DrumKid, but could never figure out a good, unambiguous way to implement it. Now that I know it's a more universally-wanted feature, I'll keep trying!
It's important to note that I have only included the negative comments in the table above! I've also had lots of positive comments, but there wouldn't be a lot of point listing them all here, besides feeding my ego. I'm likely to get a few more comments from my prototype testers over the next few days, but for now I've got plenty of food for thought.
It's a big relief that no-one pointed out any obvious, fundamental weaknesses in the design. I think I can address pretty much all of the above comments by updating the code and PCB layout (and maybe changing the type of screw that secures the back panel, which isn't a big deal).
Overall, I'm really happy with how DrumKid has been received so far, both online and in real life, and I'm excited to get started on what I hope will be the final revision of the design.
09/23/2019 at 14:39 •
Apologies for what may be a boring post, but as my target launch date (November 2019) approaches, I'm starting to think more seriously about the financial side of my project.
I'm currently planning to make small batches of DrumKids myself, perhaps 5 or 10 at a time. If there were to be a really big demand for DrumKid in the future, it would certainly be possible to redesign it in a way that would be more suited to mass production. There are surface-mount versions of all the components I use, and the case is not a particularly complicated shape, so it would be possible to design a version for injection moulding.
However, this post will focus on the economics of manufacturing on a much smaller scale. The current design uses only through-hole components, partly so that I can make DrumKid without a reflow oven, partly so that I can sell DrumKid as a kit, and partly to make each one easier to repair or hack. I'm also using a laser-cut enclosure for the same reasons.
This is my first time making anything that will be sold to the public, so it's entirely possible that I'm leaving out some major part of the calculation. With that caveat in mind, though, here are the various costs involved in making a single DrumKid unit (including both time and money as costs, since I obviously want to be paid for my time working on each unit!):
- Materials (total £19)
- Circuit board (£3 from China)
- Laser-cut parts (£2 each from local maker)
- Electrical components (£12, from three different suppliers)
- Structural components (£2, from one supplier)
- Assembly time (total 60 minutes)
- Soldering (40 mins)
- Uploading firmware (5 mins)
- Testing (5 mins)
- Screws etc (5 mins)
- Bug-fixing (5 mins?)
- Miscellaneous (total 30 mins?)
- Postage and packing cost (can be passed on to customer)
- Time spent packaging each unit
- Time spent going to the post office
- Time spent ordering parts
- Time spent organising parts
- Repairs (at my expense if within X years?)
- Development costs
- Time spent developing DrumKid (maybe 200 hours?)
- Cost of components etc used in prototypes (approx £200)
I have given actual values for the materials (because I can look up the prices I paid for them) and assembly time (because I kept a log of how much time each process took when I built a test batch of three units). I have only given values to the nearest GBP, since these costs will fluctuate quite a bit anyway.
My ballpark (rounded-up) figure at the moment is £20 (or $25 USD) of materials per unit, with roughly an hour of assembly time. The other time costs are a bit harder to estimate right now, since they will depend on factors (partly) beyond my control, such as how many units I sell. My rough estimate is that ordering parts, shipping, and general organisational tasks will add perhaps 30 minutes, on average, to each unit. This means each DrumKid unit will require £20 plus 90 minutes of my time.
This sounds pretty good so far, but I haven't yet taken the development process into account. I've spent countless hours developing DrumKid, trying out different circuits, playing with the code, soldering prototypes, researching components, etc. If I were to start the project again, perhaps I would have documented all the time I spent on development, in the same way that I fastidiously document my time when working as a freelance web developer. However, it's not as simple as adding up all the time I spent working on this project and trying to make sure I'm paid for it - a lot of my time working on DrumKid has involved learning new skills which will help enormously on future projects. Before DrumKid, I knew barely anything about PCB design, filter circuits, decoupling capacitors, or PWM audio, so I'm not sure I can strictly add the time learning those things into the "development time" column.
Since I didn't record how much time I spent on each task, this is all moot anyway - it's just an interesting point to consider. I'm going to have a wild guess that I spent 200 hours developing DrumKid, including the time I spent on the original web app version. I also spent around £200 on materials while developing the various prototypes.
Using these estimates, I can start to calculate how much I need to sell each unit for. My priority is not to "see what price the market can stand" (I'm not much of a capitalist), but rather to make DrumKid available to as many people as possible at a fair price, while earning a fair wage for my time working on it.
Since the development time/cost is already fixed (at least until I start working on the next version), the amount I end up earning per hour for making DrumKid units will vary depending on how many I sell. I've had some positive indications that there will be good demand for it, so I'm going to make a wild initial assumption that I will sell at least 50 units. I've also had several conversations with friends and musicians about how much to charge for DrumKid, and £80 seems to be a reasonable figure, so let's look at the numbers based on selling 50 DrumKids for £80 each...
£80 multiplied by 50 is £4000, which would then be my gross income from the DrumKid project. Each unit costs around £20 in materials, and I spent £200 during prototyping, so that's actually £2800 net. I've estimated that I would have to do 90 minutes of work for each unit sold, which would be 75 hours in total, plus the (roughly) 200 hours I spent developing DrumKid. This means that, if I ended up selling 50 units, I would earn £2800 over 275 hours, which works out at £10 per hour.
£10 per hour is the "living wage" where I live in Oxford, England, meaning that I ought to be able to subsist while earning this, but I would definitely prefer to earn more than this.
Of course, it's possible that some of my numbers are way off. If I sell 100 units, and it turns out I actually only spent 100 hours developing DrumKid, I could earn £23 per hour, which would be great. Then again, I might only sell 10 DrumKids - it's impossible to predict.
My conclusion from all of this conjecture is that £80 ($100) is a reasonable price to start selling DrumKid for, although I reserve the right to change my mind before release! Working through these numbers has also made me realise the importance of accounting for my time, even on a "fun" project like this, so I will endeavour to do this from the beginning of my next project. I'm sure I will find hidden costs that I hadn't considered as I near DrumKid's release, but for now I'm happy that I've got an overview of the financial side of the project.
- Materials (total £19)
09/20/2019 at 16:12 •
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.
Update: I had a good chat with an artist friend of mine about the various possible colour schemes. He, unprompted by me, also picked the all-red and red-and-fluorescent-yellow designs as the best ones, so I am pretty certain that I will order the next PCB in red, and may end up ordering two sets of laser-cut parts, one in red and one in fluorescent yellow.