As I began to make my first concept images, a practical difficulty of the radial grid presented itself immediately: the innermost grid cells were unusably small. I discovered this difficulty when I had trouble lining up the Photoshop paint bucket tool to fill in the cells. If I struggled to hit the targets with a one-pixel crosshair, how would users be able to accurately hit them with fingers on a touchscreen? This problem turned out to be the single greatest design conundrum of the project, and it took a series of iterations to solve.
The three-dimensional torus solution
My fellow Music Technology student Don Bosley was interested in possibly collaborating on a commercial version of the Drum Loop, and convened a group of programmers and designers to discuss the idea. One solution to the target area problem was proposed: instead of a two-dimensional radial grid, we could map the grid to a three-dimensional torus. The advantage was that each grid cell could then be generously sized. However, only a few rings would be visible at a time; to access the others, the user would need to somehow twist the torus inside out. We nicknamed this solution “the groove donut.”
The idea continues to intrigue me, but it has two main difficulties. First, representing such a mathematical object is a significant programming challenge. Second, there is an existing rhythm app that uses a toroidal representation of time, The Donut by Strange Agency, shown below.
It is an appealing and futuristic looking interface, but after considerable effort, we were unable to make any sense of it. We therefore abandoned the “groove donut” idea quickly.
The spiral ramp solution
A drum loop unspooling in time has the topology of a spiral, not a circle. The drum patterns could be visualized using a spiral “parking garage” ramp, the Riemann surface f(z) = log z. Below is a hand-drawn rendering of such a spiral ramp by Penrose (2004).
However conceptually elegant this solution would be, however, it posed the same practical obstacle as the “groove donut,” or really any three-dimensional object rendered on a two-dimensional screen: only a portion of the ramp would be visible at any one time. The user would have to continually rotate the ramp in three dimensions. This ran against my requirement of simplicity, in addition to the programming challenge it would have posed.
The logspace function takes in three values a, b and n, and generates n points between decades 10^a and 10^b. We generated seven points between decades 10 and 1 and normalized them to fit within the total size of the grid:
(1.0-((logspace(1.0, 0, 7))./10));
This solution produced equally-sized cells throughout the grid and made for an attractive graphic, but it was still ultimately unsatisfactory. The innermost cells became long, narrow wedges, and the outermost cells became thin arcs. Both shapes were still difficult target areas.
Radii at equal intervals
When we began the iOS version of the Drum Loop, Christopher quickly threw together a grid with equally spaced radii for expediency. We had this version under our eyes for several weeks, and during that time, its attractiveness grew on me. It is simple and clean-looking, and has the added virtue of being easy to represent algorithmically.
How, then, to reconcile these advantages with the problem of uneven cell size?
A new approach to the radius problem was inspired by Eric Rosenbaum’s sampling application MmmTsss—the name refers to the sounds you make with your mouth and throat to simulate a techno beat. MmmTsss is a simple multitrack looping program, with each track represented by amplitude blobs around a circle. The circles are concentric, and each new track adds a circle on the outside, pushing the existing circles inwards. As the user selects a circle, it expands to fill most of the application window. This is as an exceptionally elegant solution to the problem of inner circles being unusably small, and inspired the ultimate solution to the ring sizing problem: varying their size dynamically.
In the Drum Loop, tapping the name of a drum sound while playback is stopped makes its home ring double in radius, while the other radii become proportionally smaller to accommodate it. (I misremembered MmmTsss as working this way, rather than simply zooming in and out.) The target area becomes reasonably sized, and also reinforces the connection between the name of the sound and its corresponding ring previously indicated only by color. The size cue also makes the app considerably more accessible to colorblind users, a requirement we discovered inadvertently during testing of the Max prototype. This image shows the Funky Drummer exercise with the snare drum ring selected:
The variable ring size also solves another problem that unexpectedly arose during testing of the Max/MSP prototype, that of visually indicating which ring plays which sound. An obvious solution would have been text labels within the rings themselves, but that proved to be an unworkable solution. Either the text paths would need to curved algorithmically or each label would need to be a static PNG. Either way, the text would layer awkwardly with the other information presented in the grid, and would become unreadably small toward the center of the circle.
The rings default to being equal in radius. This makes the area of the outermost ring much larger than the inner one. While this initially appeared to be a design deficiency, it became apparent that it had advantages as well. Placing more salient sounds on the outside rather than the inside gives visual reinforcement to their greater importance. The foundational kick and snare are larger than more “ornamental” sounds like tambourine and handclaps, and therefore seem more significant.
During playback, sounds can be entered live simply by tapping the name label. Some users will prefer entering sounds this way, especially if they have some percussion experience. This mode makes the target size within the grid irrelevant; now we need only be concerned with the size of the labels, which are quite generous.