Saturday, 19 May 2012

Arduino Drum kit, part 4 - Arduino considerations

Hello everyone, quick update on this:

I've recently purchased a new Arduino. In this case, Arduino Mini Pro, which is manufactured by SparkFun. I got mine from Proto-Pic. So why did I go for this when I've got a perfectly good Arduino Uno?

Well, a couple of things - the primary reason is that it has more analogue inputs, 8 to be precise. They'd recently been updated to be based on the 328 chip as opposed to the 168, but this latest revision includes the two additional analogue inputs. As each piezo transducer will need an analogue input, effectively each 'drum' needs it's own analogue input. With 6 analogue inputs, this limits the kit to 6 individual instruments. A possible kit would be:
  1. Bass Drum
  2. Snare
  3. Hi-Hat
  4. Crash Cymbal
  5. Tom High
  6. Tom Low
This is a pretty cut down kit. Not exactly terrible, but it would be nice to have more. With two more inputs, a ride cymbal and a floor tom could be added. This covers pretty much all the fundamental parts of a drum kit.

It's important to note that there is slightly more flexibility than at first glance - such things as a hi-hat pedal don't make sense to be implemented with analogue inputs, it's essentially just a lever to open and close the hi-hats. In this system, a simple switch could be attached to a digital input of the arduino which would modify the message being sent as the 'hi-hat' MIDI note to 'open hi-hat' or 'closed hi-hat'. Additionally, some people just plain don't care about dynamics. For those willing to give this up to have a greater range of instruments, a switch or sensor could be wired to a digital input instead. This would mean that when triggered, the MIDI message would have to contain a preset velocity value. Admittedly the way a lot of records are recorded nowadays (specifically metal!) have bass drums recorded at full blast, or are replaced with samples played at full blast. So it may not be such a bad way of approaching things....

Secondly, I have an FTDI USB to TTL converter cable. Programming with this means the Arduino has no requirement for any extra USB circuitry, this cable just plugs straight in to the header on the side. These cables are quite expensive but handy, and quite quickly reduce costs elsewhere. If you intend to make a couple of projects in this way, you would most definitely get your money back by the savings on Arduino boards. And they're used for all sorts of other stuff too!

Thirdly, it's TINY. Which is awesome. A pic for comparison:



That's a 3.5mm jack to 6.35mm plug converter next to it, the actual plug is around 3cm long. So smaller, simpler hardware and with better analogue I/O. What's there to lose? The craftier among you might have noticed I've not actually soldered the headers - I was testing for size :P With the exam period in full swing, time is at a premium, so all progress on this is sadly suspended until exams are done...

Arduino Drumkit part 3 - a note on velocity control and I/O

While my Arduino is being used elsewhere, I felt this would be a good time to cover one of the more important features of the MIDI protocol - Velocity - and how I intend to implement this into the system.

Velocity is an indication of how hard the instrument (be it piano key, drum pad or guitar string) has been hit. As you'd expect, this is to try and emulate the natural dynamic response of acoustic instruments, which get louder if you play them harder.

So without velocity, what are we left with? A drum kit that has no dynamics. It will just play loud all the time. This might sound like a small price to pay for cost, but it severely limits how convincing an instrument sounds to the listener. As the great John Chowning (inventor of FM synthesis) once said:

          'Many natural sounds seem to have characteristic spectral evolutions which, in addition to providing their 'signature', are largely responsible for what we judge to be their lively quality. In contrast, it is the largely fixed portion spectrum of most synthesized sounds that so readily imparts to the listener the electronic cue and a lifeless quality' *

Although the context is slightly different (he was talking about sythesisers needing more dynamic qualities), the message is the same - dynamic quality is a very good thing. Variety being the spice of life, and whatnot.

The way a lot of samplers deal with velocity is interesting. As anyone who plays an instrument knows, playing and instrument louder or quieter doesnt just change the volume, it generally changes the sound also. Cheaper drum samplers will take one sample, and control the volume of that proportional to the velocity. This doesn't sound particularly good. More expensive samplers, such as Native Instruments' Studio Drummer, Toontrack's Superior Drummer 2.0, have multiple samples per instrument for each velocity level. They record a drum being played at a range of velocities, and map these samples to the MIDI velocity level. This sounds much better.

To this project, velocity control is not essential to the operation of the device, but it is essential to it having a chance of sounding nice and dynamic. The way this will be implemented is by means of peak detection (hopefully written in software to keep costs down!) that will be able to detect what is called 'local maxima'. Local maxima means that say, if a small peak and a big peak were sent one after each other to an input, the device would be able to detect them both. This is opposed to a 'peak value' - a maximum threshold that will trigger once a voltage becomes bigger than the threshold value - which would only be able to detect peaks above a certain level, and would result in all velocity values being the same.

The gradient of the incoming signal can be analysed to detect peaks. Over a peak, this is how the gradients will look:

   ^               g = 0
   |                  /\
   |   g =  +    /    \     g = -
   |              /        \
   |            /            \
  --|-------/               \-------------------->
 (better diagram coming soon!)

To implement this algorithmically, a few samples of the incoming signal can be stored and compared. If the values are increasing, a peak is about to happen. If the values have stopped increasing, a peak is reached. If the values are decreasing, the peak has passed. An algorithm can be written that will analyse the difference between the last 3 or so sampled vales of the input. If it detects an increasing signal, a 'flag' can be set (change a known variable to '1' or something) to denote it is expecting a peak. When the signal starts decreasing, the flag can be set to '0' and the last biggest value of the input can be used as a peak. This value can be mapped to the MIDI standard's 127 levels of velocity. And there you have it! Well, hopefully. This hasn't been implemented yet. If anyone else has got some good ideas about this, I'd love to hear them!


*This paper is freely available - and it's a good read! Check it out here.

Arduino drum kit, part 2 (The Blastmachine!)

Hi everyone, some more info on the Arduino drum machine...

The state which I left the drum kit in before my Arduino had to be repurposed for university work is covered in this post. The first thing I did was to test how well MIDI works with the Arduino with a simple test from this site:

http://arduino.cc/en/Tutorial/Midi

All the code and stuff in the link above is already in the Arduino IDE under Examples -> Communication -> MIDI.

Sending MIDI messages with the Arduino is very simple. RS232, the standard communications protocol that the Arduino (and all sorts of other things), is almost exactly the same as MIDI. The only thing that needs doing before using simple Serial.write commands is setting the baud rate to the MIDI standard - 31250 baud, which is shown in the link above. The program provided transmits a whole range of notes. The code can be modified to just send one note by removing the 'for' loop and replacing where it says 'note' with the note that you want. This note is in hexadecimal, so use this for reference:

http://www.wavosaur.com/download/midi-note-hex.php

(I may create a better diagram later on)

The example code creates a 'note on' message. This contains the note number, velocity and channel. For those not familiar with MIDI, velocity emulates the speed at which a piano key or any other instrument is hit, therefore bigger velocity translates to louder sound.The maximum velocity level is 127, minimum is 0, which translates to 0x7F and 0x00 in hex respectively. It is standard practise to send a note with velocity set to 0, as opposed to using the dedicated 'note off' command.

In my setup, I'm using a drum sampler within the recording software Cubase. Cubase is full of all sorts of good stuff, but the bit that we're concerned with here is its VST hosting capability. Whats that? Well, a VST is a virtual instrument that can, amongst other things, accept MIDI and output audio. A VST host sets up the environment for providing the MIDI and audio I/O. I'm using Cubase as a host and Native Instruments Studio Drummer as the instrument, but free alternatives exist, and I hope to write something about this towards the end of the project. Because free alternatives are always a bonus, right?

To test this MIDI communications functionality, and with a certain level of control, I hooked together the MIDI output as specified on that example page, a couple of switched and a couple of LEDs...

(CODE COMING SOON!)

In this case, the code waits for an input from the switch before transmitting a MIDI note. There's one button to trigger the bass drum note, and one to trigger the snare note.

I'd like to add - this has been very poorly coded and you'd never try and run a proper drum kit this way, this was just to test the thing. However it had a quite funny side effect - if you hold a button down, it will continually cycle and play the sample very fast. If you hold down both buttons, it will alternate between both very quickly, and essentially emulates a traditional 'blast beat', the staple drum pattern of extreme metal. Awesome! Good example of what I'm getting at here:



Let's compare...




Thursday, 17 May 2012

Arduino Drum Kit, part 1

Hey everyone, heres a fun project that I've sadly had to halt while my Arduino and time was committed to university work.What I hope to do with this blog is write down some more discussion-based aspects of the development, and then when the thing is done, put up an instruction guide or something similar with design files and whatnot.

The basic plan is this - create an electronic drum brain with an Arduino, where the input is a set of piezo transducers attached to some form of percussive pads, and the output is MIDI messages corresponding to notes. This system will send MIDI messages to a computer, which will in turn play the appropriate drum samples.
Sounds very simple... And quite conveniently, the bulk of it is! And most electronic drum kits Ive come across use very similar methods. In fact, wire up a piezo to a jack plug, plug it into almost electronic drum kit you care to mention, hit it and you'll most likely see it work. So the question you may be asking is 'why do electronic drum kits cost so damn much?' well, the answer quite neatly sums up the limitations of my project. Commercial electtonic drum kits generally have these sorts of features:

  1. Nice hardware - racks for the pads to sit on, nice pads made of durable materials, decent piezo sensors, pads with multiple sensors (think ride cymbal pads with bells as well) e.t.c. Made to go on the road!
  2. Large amounts of I/O - allows the user to attach a ton of pads.
  3. On board samples - increases the specification of the system considerably in terms of memory and storage to hold the samples. Anyone who's worked with digital audio knows - storage and fine quality audio aren't the best of friends.
  4. Other digital features - complex interfaces, additional MIDI features, custom patches and sample sets, things that increase flexibility to the user.

In short, these are things that make electronic drumkits nice, self contained instruments that require little external technology for proper operation. For this project - almost none of these things will be included to keep costs as low as possible. But how will it work with no pads, very little I/O and no sound to play?
What this project is intended to be is the very fundamentals of a drum 'brain'. As it happens, most of the features mentioned above are great, but not neccessary. Rather than onboard samples, sounds are sorted on the computer via a drum sampler and VST host (more on that in part 2). Rather than huge I/O options, the limited Arduino analogue inputs will be used. Rather than nice pads, the sensors will be attached to whatever you can tape them to and dont mind hitting! This is a brief overview of the system.

 
Some projected costs, taking the cheapest in each case:
  • Arduino - £18
  • Piezos - can be found for around 30p each. A set of 6 would therefore be £1.80.
  • MIDI cable - around £3.
  • MIDI interface (omitted from diagram) - cheapest I've found is around the £20 mark.
  • VST host - Free!
  • Drum Sampler - Free!
  • Materials - going to attempt to make pads from butchered mousepads initially. Picked up three for £1.
  • Drum sticks - £4 if you're feeling fancy. Any old pen you have lying about, if not.
This sets a ballpark figure of £47.50 - half the price of the cheapest drum brain I can find! Most of these costs are from a quick check online and I'm sure they could possibly be found cheaper. If you've found these things cheaper, that's great! (and let me know!)
A more detailed breakdown of costs will be included at the end of the project.

I hope to extend this system and add all sorts of usefull bits and bobs. Velocity control would be a particularly useful feature,  which I hope to cover later.
Ill be adding more information about this project over the next few days.
Thanks for reading!

Wednesday, 9 May 2012

Greetings!

Hello all!

So what's the deal with this? A place to publish progress on any electronics projects I'm working on, largely focusing on the awesome Arduino platform. In the spirit of open source development, I intend to share all code, designs and such in this very space! In line with many other Arduino project sites, I'll also endeavour to keep the language clear and simple so that it's (hopefully) accessible to all. Project-oriented content may be at a minimum initially as I'm currently in the process of wrapping up my final year of university (and more importantly, my Arduino's been re-purposed for that!). But we'll see, eh?

Thanks for stopping by!