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.