I’m planning to be done with my thesis by (gulp) December. My collaborator Chris and I got a basic prototype of the radial drum machine together over the summer using Max and Javascript. What we learned is that you don’t want to do an audio app in Max and Javascript, since it will be single-threaded and slower than molasses in January. Since then, we’ve been building the iOS version, which is going to include more features and be closer to the version I have in my head.
The big design problem we’ve been struggling with is this: you want to have a variety of drum sounds to work with. Each one needs to live in its own ring. However, the more rings you have, the narrower each one has to be. I wanted eight slots for sounds, but then the rings are too small to easily click. Also, the innermost wedges have to be really narrow, and the outer ones absurdly wide. So it was really a challenge to optimize the size and spacing of the rings. The first idea was to logarithmically space them so that the inner ones would be spaced further apart than the outer ones. That also made the cells approximately equal in size. Here’s the Funky Drummer beat under the old system:
Clever though this solution was, it had two big problems. One, calculating all the logarithms was a pain. Two, it still only let us fit in six rings. A solution presented itself when Alex Ruthmann pointed me to MmmTsss by Eric Rosenbaum, a simple music looping app with a radial interface. Eric’s bright idea was to jam in a lot of rings, and let you easily zoom in and out to see each one at a reasonable size. I thought of a parallel idea, having the actively selected ring expand in size and push the others out of the way. The rings could now be any width without compromising usability. Chris had been using equally spaced rings in the iOS version for expediency, and we both preferred the way they looked. Also, having different numbers of sounds for different patterns would be easy that way, since all we’d have to do is divide the total radius by the number of rings.
My friend Leo, an ace jazz drummer, tried out the Max prototype, and asked if there could be numbering on the wedges. Simply color-coding them left him counting his way around the circle to find the backbeats and so on. He was right, numbers make things easier for experienced musicians, and novices can learn how the counting works just by watching the playback head sweep past the numbers.
I had originally decided that the more basic drums — the kick and snare — should go on the inside, and the more decorative ones — cowbell, clap and so on — on the outside. I guess the idea was that more important sounds should be more central. We realized, however, that it would be smarter to put the most salient sounds in the outer rings, where the cells would now be bigger.
We didn’t get around to implementing swing in the Max prototype, but here’s how it’s going to work in iOS. Since swing is alternate lengthening and shortening of every other beat, I thought it would be cool to visualize it by making alternate wedges thicker and thinner.
We had included the option of counting in either eighth or sixteenth notes in the Max prototype, which behind the scenes just multiplied or divided the tempo by two. With numbered wedges, the distinction will be a lot clearer. Here’s Take Me To The Mardi Gras in sixteenth notes.
Amar, my classmate at NYU, tried the prototype and complained that because he’s color-blind, he had a hard time differentiating the different drum sounds based on color alone. The variable ring size helps with that. You tap the name of a sound, and the corresponding ring gets bigger, voila. Here’s Take Me To The Mardi Gras with the high bell selected, shown in pink:
This isn’t exactly right, because I just knocked a ring out rather than resizing all of them. But graphics are hard, so.
For the future:
- Putting in the actual drum programming lessons. They’re in my head, just not in code.
- Live drumming. In the prototype you could only enter drum patterns by entering them into the cells with the mouse. There was no way to play live. That has to be addressed. Probably will do live beat entry by tapping the name of a drum sound. The app will automatically quantize the input.
- Velocity. Right now drum hits are either on or off. The plan is to have them default to 70% loud. You’ll be able to hold your finger down on a given hit to bring up a velocity slider. The question is, how to represent velocity graphically? With differing transparency levels? Different colors? Haven’t settled it yet.
- Multitouch. One cool multitouch gesture I have in mind is the ability to grab a ring and rotate its contents, to hear the effect of displacing a rhythmic pattern.
- Alex suggested integrating recordings of the breaks in the context of their original recordings. I could skirt the copyright difficulties by using the YouTube API. Furthermore, I could do traditional notation versions of all the breaks using Noteflight, and then sync those to the YouTube videos too.
Suggestions? Ideas? I’d love to hear them.
Update: here’s a screencap of Chris’ iPad showing the present state of the app. The boxes light up when you touch them! Exciting.
When I saw the image of your new interface, I was struck that it seemed “odd” to me. What that was is that you have centered the beat spaces around the cardinal degree points on the circle (0, 90, 180, 270). This biases the touch point in that the cardinal points line up with where you want people to touch – the center of the button I assume. My initial assumption was that layout is more clear when you have the starting edge of the beat line up with the cardinal points. I’m not disagreeing with this layout at all. I just caused me to think about the design, usability, and intuition.
I’m schooled to think about visual representations of beats that have the time-based starting point of the beat line up with the cardinal points on the circle, rather than the visual center of the beat lining up. Which layout is more intuitive or user-friendly to your users? One that biases aural starting points or visual tap/performing points? Perhaps it’s also a matter of what your experience design, intent, and purpose is for your users… if you were using this as a “doorway in” (Wiggins, 2001) into rhythm as proportional duration, then maybe you’d bias toward the aural based cardinal points. But, if you are focusing at the beat pattern level – and filling in patterns, perhaps your way of laying it out makes most sense? Is this something you have thought much about?
The choice to center the boxes rather than the divisions is a deliberate one. I do indeed want to bias people toward the center of the touch point. It would be easier from a programming standpoint to line up the edges with the cardinal points instead, and it would be more correct in terms of where the beat onsets occur. In fact, that’s how I originally had it. But it just felt “wrong.” I’m going more for the spirit of a time-unit box system, where the musical events are like lego bricks. I guess this design does steamroll over the idea of event onset and ending, but I see that as a feature rather than a bug. I’m making no attempt at representing proportional duration; the pattern is more the point. All of that said, I’m not opposed to A/B testing the two approaches, it would just be a matter of commenting out a few lines of code…