The Drum Loop development process

I collaborated closely on the technical aspects of the Drum Loop with my fellow masters student Christopher Jacoby. He graciously agreed to give me extensive assistance in exchange for jazz guitar lessons and music production tips.

Chris with an iPad prototype

Christopher’s contributions to the project include substantial guidance with Max coding and a wide variety of specific feature implementation methods; implementation of the Max prototype’s user interface in JavaScript UI; and considerable insight into the problem of maximizing target areas on the grid. He also learned Objective-C and the audio and MIDI functionality of iOS while simultaneously developing the back end of the app.

I created the user interface design, including all guidelines and requirements. I also developed all musical and pedagogical content. We received additional assistance on iOS audio implementation from NYU PhD student and programming instructor Oriel Nieto, as well as from the Stack Overflow community.

Before developing the iOS app, we first created a working prototype using Max/MSP/Jitter. This prototype was intended as a “minimal viable product” and implemented only the most basic functionality. After we completed the Max prototype and I performed some testing with it, we faced the choice of whether to continue to develop additional functionality in Max, or whether we should start over in iOS. We opted to move forward using iOS, even though that meant revisiting solved problems. Or so we thought—iOS turns out to be dramatically more difficult to work with than Max, and seemingly simple problems like polyphonic sample playback consumed considerable development time. It is our hope that this effort will have turned out to be worthwhile, for several reasons:

  • Max is not suitable for robust commercial software releases. It is optimized for ease and accessibility while developing, not for producing well-optimized and stable code. Furthermore, each application created with it is platform and operating system specific. Of course, iOS apps are locked to a platform as well, but iPad usage continues to grow explosively, particularly in schools, so this limitation should prove less burdensome.
  • Unlike the Max prototype, the iOS app sends and receives MIDI messages. This creates the possibility for having the Drum Loop communicate with other hardware and software via MIDI as well.
  • There is a robust ecosystem of iOS music apps that can send and receive audio to one another in real time using inter-app audio. A user might set up a pattern in the Drum Loop, improvise a synth lead on top with Animoog, and record them both in Garageband.

Over the long term, we also plan to adapt the Drum Loop into a web-based app running entirely within the browser, using the emerging HTML 5 web audio standard.

The Max prototype

We created two functioning prototypes with Max. The first is highly skeletal. It uses simple Button UI objects arrayed in wedges, that are themselves arrayed around a circle. The inner ring of buttons shows kick drum hits as blue dots; the second ring shows snare hits as red dots, and so on. By clicking each button, the drum hit in that slot can be toggled on and off. The downbeat is at twelve o’clock, and playback runs clockwise. The playback head is shown as a row of yellow dots sweeping the circle like a clock hand.

Radial dots

Drum patterns can be stored, retrieved and played back from a Jitter matrix.

Drum sequences storied in a Jitter matrix

The second, more full-featured Max prototype used the same back end, but had a more elegant user interface. In order to implement it, we had to find the best method for creating the radial grid. My initial plan was to simply create static PNG images for the empty grid, the filled cells, the playback head, and any additional graphics needed for animation. We would then display and hide these images as needed, and map regions of the screen for hit detection. This method had the advantage of superficial expediency, since I would have been able to produce the necessary images myself very easily. However, it would have been a cumbersome and inflexible system, requiring new sets of images for every possible number of wedges or alteration to the design scheme.

The alternative to static images was to render the grid, filled cells and animation entirely in code. Christopher advocated for this approach, since it is better programming practice and offered the greatest flexibility for design changes. Christopher suggested using JSUI, a Max object enabling interactive graphics using JavaScript. He was able to learn the syntax in a matter of hours, and I was not far behind. We were able to create a working user interface in a few weeks.

The Drum Loop - Max prototype

Accessible though it was, the combination of Max and JSUI had significant performance disadvantages. Max is optimized for ease of programming, not performance; the standalone apps it produces are notoriously slow. To make matters worse, JavaScript is a single-threaded language, placing a severe bottleneck on the app’s throughput. While the prototype loaded and ran on the various computers I tested it on, it was quickly overwhelmed by the demands of polyphonic audio playback and continuous screen redrawing. Within a few minutes, the prototype became slow to respond, with lags of several seconds between mouse clicks and corresponding action. Thirty-two step patterns and faster tempos overwhelmed the prototype instantly.

While performance limitations were to be expected, the Max prototype suffered additional problems from our less-than-optimal algorithm for drawing the grid. JavaScript lacks a good method for drawing complex shapes using Bézier curves, so we were forced to generate the interface using simple wedges. The outermost ring of cells was actually a set of wedges originating at the center of the grid. The next ring inwards was a set of wedges extending not quite as far from the center. Each ring was its own complete set of wedges, all of which were redrawn every time the screen refreshed. This method would have performed poorly regardless of the language in which it was implemented.

The iOS app

It was always my intention to create the Drum Loop in iOS. While there is no logical distinction between clicking on a grid cell with the mouse pointer versus tapping it with a fingertip, the latter has significantly greater intuitive appeal. Furthermore, iOS offers the possibility of multitouch control. However, iOS is also a significantly more challenging production environment than Max.

Below is an example screenshot of the iOS app. The functionality is much the same as in the Max prototype, though with several cosmetic differences.

The Drum Loop - iOS screenshot

The right side of the screen shows the list of buttons triggering the eight drum sounds in this kit. The icons on the right side of each button draw focus to that instrument within the grid—that functionality is discussed in depth below. The center shows the drum grid itself. Unlike the Max version, here the outer ring holds the snare drum. The next ring inwards holds the snare, then the closed hi-hat, and so on down the list. The left column contains mostly self-explanatory basic functions. The row of icons along the bottom of the screen are a sequencer for stringing multiple patterns together—this feature is still taking shape.

On the back end, the app is structured as follows. The DrumLoopViewController contains the main user interface: drum buttons, tempo, kit, swing, save, load and so on. It also contains the square DrumCircleView, which contains the radial grid itself. DrumCircleView communicates with three components. DrumWedge, as the name suggests, draws the individual wedges making up the grid. SequenceHolder is a matrix of values that stores drum patterns. SamplePlayer plays the AIFF drum samples themselves by sending messages to MIDIHost, which in turn communicates with an AU sampler unit.

Structure of the Drum Loop iOS app

4 thoughts on “The Drum Loop development process

  1. Thought about kickstarter? I’d be in. I had been dreaming of creating a radial drum app a few months before I saw your blog. Just what I need. I study and teach traditional African style percussion, but I like to mess with it and compose also.

    • No, still working on it. It would go faster if I could find a few tens of thousands of dollars to pay my developers.

Comments are closed.