Drum Programming (Part 2)
A Series By Warren Cann.
Warren Cann continues his series on drum programming.
Last month I introduced the series, discussed the approach to a new instrument via drum programming, and closed just as I began the topic of manuals. Yes, you're absolutely correct, sometimes it seems like you could have written an album in the time it took you to mess around with the manual. The 'just-a-phonecall-away' software house/manufacturer's technical representative is a great help, but often this only leads to deeper confusion and despair... there's only so many times you can say: "Er... could you repeat that, please?"
There's no easy way around it, you just have to hang in there and you will gradually master your new toy(s). What makes the whole of this learning phenomena such an issue is that just as you come to grips with your keyboard, your expander(s), your drum machine, and your sequencing software-of-choice etc, and you think you've got it all cracked, you find that different manufacturers use quite different terminology.
A Roland 'Tone' is a Korg 'Voice', which is a 'Performance' according to Yamaha, and that these are considered to be a 'Group' according to Ensoniq, all of which, naturally, is referred to by Kawai as a 'sound' even though Oberheim see it as a 'Module' because they wouldn't want it to be confused with Akai's 'Patch' or Kurzweil's 'Map' in spite of Emu calling it a 'Wave'. Are we having fun yet? A certain manufacturer even has the effrontery to label its Record and Play buttons as 'Compose' and "Perform'... get real, guys.
It's difficult enough coping with what's immediately in front of you; it's insult upon injury to discover that, as you acquire equipment, you not only have to learn how to use it for its intended purpose but that you also have to learn the particular technico-linguistic slant of that manufacturer's design team (which, naturally, never seems to mesh with anyone else's). It's a pity that the MIDI Manufacturers' Association can't get together and agree on terminology in addition to their other standardising efforts.
Manuals often hinder the learning process rather than help. Between engineers who know the stuff so well they're incapable of remembering what it was like to not understand it, and translations that were obviously never read by anyone whose mother tongue is English, there have been a few real turkeys written. The best ones are greatly appreciated because they're clear, concise, do not take your experience for granted, and literally take you through operations step by step. OK, it's real "See Dick throw throw the ball. See Jane catch the ball. Nice ball." stuff, but that's exactly what you want at that stage. It goes almost without saying, however, that the particular action that you want to perform, or are curious about, is not covered...
When I acquired my Atari ST/sequencer package, I did so because I could see how it worked and knew what it could do, I knew its potential, and wanted to use it. I set it up, and promptly ran aground on the shoals of complication. I'd sit there at the computer determined to crack the thing, but eventually I'd throw in the towel after getting sidetracked in a labyrinth of not-quite digested chapters. I think what really got to me was the voice at the back of my head that said, "Wait a minute... I've probably got a headstart on most musicians regarding this equipment, I've a reasonable technical grounding in this, I understand what is supposed to be happening here; so why am I so lost!?! And, if I'm having this kind of trouble, then how are other people making out?" In the case of that particular software, it was just an incredibly naff manual; it told you everything you could possibly ever want to know about what it could do — it just didn't bother with explaining how you actually went about doing it. So many people made so many complaints that the manual was eventually totally rewritten.
In fact, there is now a small but flourishing publishing market in the supply of independent, third-party manuals written by people who realise the value to the end-user of a text orientated towards the musical considerations and practical applications of a piece of equipment, rather than the supplied manual which may merely provide 'operating instructions'.
You will encounter constant referrals-to-the-manual (unless you happen to only work within the technical isolation of one, all-encompassing workstation); the compounding of the different operating systems is something that makes this difficult to avoid unless you work with the same equipment every single day, day in and day out, for a long period and get up to speed on it. The high-end sequencing programs can do just about everything; you may not want to do everything, but the software can still do it, in so many different ways, that the general idea is to allow you to work the way you want to work.
You'll find with high-end equipment that you reach a sort of plateau — you know enough about the thing to enable you to work the way you prefer to work, and that you only scratch further beneath the mountain of features on offer when you attempt to do something a little out of the realm of your usual working habits. What can I say, except hang in there, it will get better — sort of. Your technical problems will actually just get more exotic; they'll never completely go away.
If you've just got your first drum machine then study that manual. Familiarise yourself with the control panel and its primary operations: Record; Set Quantisation; Copy; Delete; and Erase. Leave the more advanced functions for later when you are comfortable with the basics. Don't pay any attention to the aesthetic value of the beats you create while experimenting here — your aim is to understand the first levels of the unit's capabilities so as to provide a foundation for your further work. If you've been using the machine for a while, I recommend you re-read that manual. You will inevitably find that it seems clearer than the first time you read it; you'll discover that operations you didn't wholly understand before now appear logical, and you'll see creative possibilities within features that you may previously have thought of little use. Without complete familiarity with the machine's abilities, you will not be able to properly manipulate them later to achieve your musical goals.
After practice and experimentation, I expect you to be able to take a pattern, set a quantisation value, put the unit into Record, and program a basic kick, snare, and hi-hat pattern to your satisfaction. You must be able to copy that pattern to an adjacent location, and then over-dub percussion on to it, erasing any mistakes without damaging what you want to keep. You must be able to use the Song/Chain function to string together a series of patterns in the order that you choose, plus be able to Delete or Replace specific patterns in that chain. You must be able to execute these primary functions without confusion before proceeding.
Once you feel competent in the basic operational aspects of your drum machine, you will naturally want to program some rhythms and incorporate them in a song. Before we go further, you must appreciate that a hierarchal system works best when programming. You must begin with fundamentals, and then evolve as required to greater complication. Simple elements are added to each other — your 'main beat' (no doubt the 2-bar pattern giving you the groove that inspired you to come up with the song, the one that's been looping away on 'play' while you were writing) has variation of itself added to yet more variations of itself, layer upon layer. Therefore, don't worry initially about the mega snare fills you want to have at the end of the solo; you want to just start with your basic, constructional elements. The polish can be applied later. You must first make some decisions. Which beat is the core of the whole song? Which variation of the core beat — if any — will be used only for choruses? Does the song have a bridge? If so, will it have its own beat or will it use the same beat as the verse?
These variations, even if you envisage a very simple drum track, soon add up in surprising numbers which, ultimately, requires some sort of system enabling you to keep track of them. I must emphasise here the importance of developing a 'system' and good work habits when programming, if you've not formulated a method by which you can easily locate and identify these elements, it is very, very easy to become confused. And when you are confused you will make mistakes. Bet on it. Use my system, or any modified version thereof (change it however you see fit), and you'll be able to work more efficiently and won't get lost so often.
Yes, it is possible to do without such a system. Most people get along by just winging it, they depend on their short-term memory to see them through. Some people seem to work happily away with just the odd, scribbled note on scraps of paper to tell them what is where. They work in a linear fashion, like a tape machine: the entire song's drum track is just one, immensely long, measure. Instead of chaining together different drum patterns, they've appended each subsequent pattern that they've written onto their initial main pattern (true, most software-based sequencers allow each of their patterns to be 'open ended', ie. the pattern is as long as the information you record on it; it doesn't stop when you're in Record until you press Stop, whereas drum machines can require you to set the length of a measure first). They've become used to it, it works for them, so why should they change?
There are many reasons: three days/weeks/months later, you decide to make some changes and the scraps of paper are long gone, you find you can't remember the order of some of the subtle variations you spent so long programming, you prepare some new sections and the dynamics don't match up with the original version... In short, you'll waste a lot of time, and the benefits of using a system are overwhelming.
I evolved my grid-based 'mapping' system (by the way, I use the term 'map' only as a descriptive term, usually in a MIDI context; mapping refers to the alignment between different sets of values, ie, patch change numbers) for use in conjunction with MIDI systems through trial and error over a period of time, and I've pretty much fine-tuned it to where its usefulness to me is paramount — I couldn't envision doing without it. When you're not using a computer-based sequencing package, this straightforward, simple chart is a lifesaver. You have all of the information regarding what you did, where it's located, what you used, and what you've shelved. You'll know the tunings, the pan positions, the pad/voice allocations, and the output routing. You'll know what file name the data is stored under and where its back-up is. If you get into the habit of keeping this data current as you are working, you won't find it such a chore later to write everything down all in one go. Besides, mistakes and lost work mostly occur during a song's composition, not after its completion — you may have use for some of your record (all of it on a bad day) sooner than you think.
Feature by Warren Cann
Previous article in this issue:
Next article in this issue:
> ST Notes
mu:zines is the result of thousands of hours of effort, and will require many thousands more going forward to reach our goals of getting all this content online.
If you value this resource, you can support this project - it really helps!