It was 20 years ago today …
It’s easy to take for granted the mature tools available for music creation, and forget their history and the folks who made them real. While today it’s one of the biggest music software developers in the world, Cakewalk‘s first sequencer of the same name started as a college project for a Philosophy major. Cakewalk founder, CEO, and original author of the Cakewalk sequencer Greg Hendershott was that student. For the twentieth anniversary year of the founding of his company (then known as 12 Tone Systems), Greg sat down with me in their Boston headquarters.
This was a personally meaningful meeting for me, as Cakewalk 4.0 for DOS (pictured above) was the first software sequencer I ever used — and remained my favorite some time after going to Windows. In those days, programmer’s names were front-and-center more than they are now, and so Greg’s name popped up every time I sat down to work. Greg also studied with Gary Lee Nelson, who was my first electronic music instructor (albeit for me at a summer camp). Of course, part of the reason it’s meaningful is that I’m far from alone — over 1,000,000 users have used Cakewalk’s software. A look at Cakewalk is also a look at the computer music software industry’s brief but fast-moving development, and the design of the tools that have evolved alongside it.
This winds up being a huge interview — you’ll believe me when I say this is basically a transcript of what Greg said. But it’s also a genuine slice of history, and also a glimpse into what the industry’s next 20 years might be like, so we’ll have at it.
B.C.: Before Cakewalk
It’s your 20th anniversary — that means now’s as good a time as ever to talk about the beginnings of Cakewalk, and where this all came from. Can you take us through some of that history?
So, I was born … no.
I think the natural place to start is that I ended up at Oberlin College. I was technically a philosophy major, but the cool thing about Oberlin is that there’s the college, and then there’s the Conservatory of Music, and they make it pretty easy to cross over. I took a few classes, but mostly electronic music. I was taking several electronic music classes a week, and then trying to put out a philosophy paper.
Who did you work with at Oberlin?
Gary Nelson and Conrad Cummings were the two people. Gary was still doing stuff in APL [programming] language, and he made some extensions that he called MPL. [To program in APL] you have to use this special keyboard; it uses Greek symbols. You can be very succinct and precise when doing vector operations. For music that came in handy, because music was usually an array of notes or pitches or other parameters. But apparently the only people who really use APL are either actuaries, in the insurance industry, and Gary Nelson for music. It was pretty cool, but I think for the average freshman electronic music student, it was a little daunting with the Greek symbols.
What technology were you working with as a student — what were the tools at the time?
What we mostly spent our time on was CP/M [Intel operating system] machines, Osborne computers using Turbo Pascal to do programming. Ed. note: Anders Hejlsberg, the creator of Turbo Pascal, and successor Delphi — in which Fruity Loops was developed — went on to be a chief architect of Microsoft’s C# and .net, so a lot of this stuff is significant down the road.
And the other gear was stuff like, I think when I was there we got the first [Yamaha] DX7 [synthesizer]. That came into the lab, and everyone was really excited — and totally baffled about how to program it, because we were used to the Moog modular kind of synths where you literally had the patch cords around your necks and were making patches by [connecting] cords. So, to figure out FM synthesis was a little tricky. Working with a big modular synth was tactile and interactive. And then you had this small screen.
That’s how I got interested in computers. I was not a math and science guy. In high school, I was much more into English and history. If it wasn’t for music, I doubt I would even have tried to learn how to do software programming. But that made it fun for me. And, of course, over the years I came to be interested in the software engineering part of it for its own sake. But in the beginning, it was the music that made it fun enough to stick with.
So I wrote software. I got out of Oberlin and I procrastinated about getting a real job. I had some temp jobs, and in my spare time I thought I would try to take this software that I had done at Oberlin and really try to start over and write a basic sequencer.
Birth of Cakewalk, and a Five-Person User Base
What was that first experimental sequencer project like, the one you did at Oberlin?
At this point, I don’t even remember. It was kind of maybe crude pieces of what you would need to do a sequencer. It’s kind of fuzzy at this point. I do remember pretty much starting over but using a lot of the concepts. You know, sometimes you write something, and in hindsight, you figure out how to do it much better. But it helps to have done that first one.
So I kind of procrastinated, and thought maybe I could try taking out a small ad and selling a few copies. And I did, and amazingly four or five people saw the ad and called up and ordered. And that was enough to pay for the ad and do another one. It was really honestly a bootstrap. In the beginning, I really kind of backed into it. I had this thing, and it’s fun, and I had enough success to go a little longer, and it took off from there. But in the early days, I’d be writing code and taking tech support calls. I’d be going down to the local UPS place with boxes before they closed at 5:30 each day.
How did you come to name the software Cakewalk?
Right before I placed the ad, literally two days before the deadline, I had picked another name for the program, and I found out it had been used by other software. I think it was something like Opus. So I had this little dictionary of music terms, and I saw Cakewalk. And I thought, wow, that’s nice. It’s a simple English compound word, you know how to spell it, and it has this connotation of ease of use even if you don’t know the musical history.
And what about “12 Tone Systems?” Because who doesn’t like twelve-tone music, I guess, right?
So the name of the company was 12 Tone Systems — because it’s everyone’s favorite, most accessible style of music. [laughs] I thought it was kind of fun. For many years, people would call up and say, “is this Cakewalk?” I decided, instead of correcting people, we’d just change the name of the company to Cakewalk and that’d be simpler.
Early Evolution of Cakewalk, and Long-Lost Competitors
What sorts of things did you have to change for the program to evolve?
I think that the very first versions, behind the scenes was all one track, and all the events were in some big, huge array.
That was the other thing I did when I threw away what I had done in college. I actually did that in C. And remember in those days, too, this was strictly a MIDI sequencer, so it was only transmitting MIDI events to be used with external gear. I think back then I had a Roland MT-32, a Yamaha FP-01, and a Sequential Circuits 6-track. I actually owned a Commodore 64 when I was in college and tried to do some programming with that. I had some weird cartridge from Sequential that you’d plug into your Commodore 64 and it’d talk to your six track.
I think [Cakewalk 4.0] might have been the first version that would work with other MIDI interfaces. In the beginning there was the Roland MPU-401, and it had kind of a smart mode and a dumb mode. Ed.: that’s in fact just what they were called, though not necessarily accurately! The smart mode, you’d give it for example a note and a timestamp and it would transfer that MIDI message at that time. And it had some other features. So in a way it made it easier, but you got locked into certain things, like I think it had 8 tracks I think that it could handle. So Cakewalk for DOS had 256 tracks, and I had to come up with some scheme to take each eight and combine them. And then there started to be other MIDI interfaces that were simply UARTs, simply a serial port without the smart mode chip. And I wanted to try and support those. I think it was version 3 or 4 that I had to go back and rewrite [the software.]
At the time, you were really one of the first major sequencing programs to be available for DOS, correct?
There was a company called Voyetra that had a program called Sequencer Plus. And Roger Powell had a very pattern-based kind of sequencer. Right out of college, there was no way I could pay $500 for Sequencer Plus. So that’s part of why I started to write my own software. I think my motivation back then was to make something that was easy to use, and maybe a little bit more affordable. I was influenced a lot by a company called Borland, and back then they had … Turbo Pascal among other products. They had this whole philosophy, they would make the software affordable, they would not use any copy protection, which was pretty unusual back then, and that kind of basic business model or approach to software really appealed to me, so I borrowed a lot of that in Cakewalk.
Design, Then and Now
I remember having a really strong impression of Cakewalk 4.0 for DOS’ original design, and its simplicity and elegance. Now, obviously, in terms of capabilities and technological evolution, SONAR or anything of this generation is very different from an early DOS program. But I certainly have some of the experience of that original Cakewalk in SONAR. What — if anything — from Cakewalk’s first versions carries into the products today?
My design philosophy for the early Cakewalk software was to make simple things simple and to have more complicated things require a little more effort. So anything that you’d be doing frequently, like selecting tracks or wanting to record on a track, I tried to keep that very up-front in the user interface — a single keystroke — and things that were a little less frequent I’d tried to have buried in a dialog box or away from view. I think that’s one thing that we’ve tried to keep up, although that [gets] more challenging as you have more and more functionality and more features to the software. But I think that’s one principle we try to follow: keep the simple things simple and hide the complexity.
I think today SONAR still does a really good job of that, given the incredible amount of things you can do, especially compared to Cakewalk for DOS. The surface area of the application — plus all of the windows and dialogs — is so much bigger than in the early days. But you do have the choice of how you want to present that surface area to the user. So I think that’s one point where you have some ability to deal with the complexity and decide how to present that to people. The basic approach to the track view to some extent has a lot of the same characteristics of the very early version, but with many more options. And, of course, today we have track folders and all sorts of other options. But the basic keystrokes for moving around the tracks and quickly recording one have pretty much survived from the early days. The basic views, the track view, the piano roll view, obviously continued. Some of them combined, so you don’t have to go to a totally different view to edit controller data or work with notes.
But it really has grown an amazing amount. It was just MIDI, there was no digital audio, there was no graphical music notation — it was a program for DOS, so it was all text, or little blocks for graphical-like things that weren’t really graphics. Obviously that’s been a huge change.
It’s funny to think, too, how these platforms have survived. 20 years ago was before Pro Tools, but if you look at the leading DAWs now, we have Logic that was Notator, Cubase, Performer (now Digital Performer)…
I think it’s easy for me to forget how many programs there were back then. There was the Atari platform and the Amiga platform. And on all four of those platforms [with Mac and PC/DOS] there were three or four pretty good options for people. But it was just too much to sustain over time. So eventually four platforms was just too many, and things started to really boil down to Macintosh and Windows. And on those platforms there are only so many companies — choices at any one time that can capture people’s attention and keep going.
How do you account for Cakewalk’s ability to succeed over that period?
I think we worked hard, but we were also lucky, and we had a lot of great customers who continued to give us feedback. I think in terms of secrets of my success — or our success, probably the single biggest one was we were really trying to listen to customers and take their feedback and their wish list, and really roll things into the next version quickly. Sometimes it’s as simple as listening to your customers, and they tell you what they need and what they want, and you go do it. And a lot of it is really that simple.
But at times, companies for various reasons have difficulty doing that. And it is a little tricky, because sometimes customers tell you they want something, but you shouldn’t take them too literally. So if you take what they’re asking for and do it in a slightly different way, you might be able to satisfy ten different requests that are really variations on the same theme. And sometimes [you'll introduce] things that haven’t even occurred to them yet. There are these discontinuous innovations that you won’t find out from customers. So I think you really need to season that — maybe it’s 80% listening to the customers, and 10% thinking of the things that haven’t even occurred to them, and 10% reinterpreting what they’re asking for. But I really think 80% is listening and doing as much of what people want as possible.
But some observers might disagree with you on that. There’s a lot of talk in design — software design, Web design — about trying to do less, about saying no. Ed.: Since I talked to Greg, I got to ask Ableton co-founder Gerhard Behles about some of these challenges; it’s interesting to hear different takes on this, and we’ll have that soon. -PK
My theory is, a lot of products start off — like Cakewalk for DOS version 1.0 — or maybe Ableton Live version 1.0 — in the beginning, it’s extremely focused and they can only do a few things. But the few things they do, they do very well. And it attracts people who only want to do those things, and for them, it’s perfect — it has everything they need and nothing they don’t need getting in the way.
But over time, as you try to listen to customers and try to accommodate their requests, the product becomes the union and the sum total of all the requests you’ve received over the years. If you could hit the fast forward button, go out five or ten versions, it won’t be that original, really simple — perfect-for-some-people — product that it started off as. I think some companies are able to do a better job of taming that complexity and not letting it get out of control. But it’s pretty hard after 10, 15, 20 years of adding feature requests. That’s a real challenge.
How has perception of Cakewalk evolved, particularly as you’ve expanded the feature set in this way, and had to contend with complexity and change?
I think for Cakewalk there was a period where people knew that we made software that was easy to use, but I don’t think we got credit for being as innovative as we actually were. At times I felt kind of bad for our software engineers (This was the part where I wasn’t writing code any more.) I felt like they’re creating these really amazing things, but we’re not getting credit for it. People might recognize a product like Cubase or Logic as being very innovative, but we had done the same thing two years before. So it seemed like we were maybe a little invisible with the power user community.
That was part of the motivation of doing SONAR. The later era of what was called Cakewalk Pro Audio, 6, 7, 8, 9, I think particularly then we felt that people are recognizing that our product was easy to use, but they were saying, if you’re a real power user, you don’t want to use Cakewalk, you want to use Cubase. After I while that gets to you a little bit. I think that’s changed; [we're] making sure people realize the power user features that we have. Of course, the irony is, as we did that, there’s a group of people looking at Ableton Live saying, wow, this is really cool, it’s really easy to use, it doesn’t have all these features in SONAR or Logic. I think the moral of the story is, there’s not one type of customer, and not one type of product that’s right for everyone. You need to pick your vision, and that may change over time, and may evolve. You’re not going to please everyone all of the time, and that’s fine.
As you say that, it really seems that the market today is more about differentiation, focusing on different approaches instead of just more features — sometimes even intentionally doing less. There was a period, particularly in the 90s, when it seemed to me at least it was more about one-upping features, to the point where programs began to look more like one another; do you have a sense of that, as well?
In particular, my perception was that Logic and Cubase were locked in this feature war, and if one product added a feature then the other one had to. Over time, that’s going to tend to make the products look more like each other, although Logic and Cubase have different feels, but in terms of feature set, they get more and more similar over time. As [we've been discussing], I think some people start off at a certain point in their personal experience using music technology — maybe if you’re just getting started, Cakewalk DOS 1.0 is perfect. But as your needs evolve, the product evolves with you. Other people just getting started, maybe that later version is a little daunting to them.
So I think there’s always a role for new products to come out that are not trying to have every feature the power user might want. Whether that’s Ableton Live or Reason or Project5, there definitely has been a trend in recent years to kind of take out a clean sheet of paper and say, how would we design it today? Which is not to say that Logic and Cubase and SONAR are bad, but they definitely [represent] a certain philosophy of how things should work. For a lot of people that’s perfect, but it’s not the only way. So I think it’s really fun and refreshing to see people take out the clean sheet of paper.
I think as the technology changes, it definitely makes sense, every five years or so to take out that clean sheet of paper. You may discover you’ll still do things pretty much the way things have been done. And sometimes you may realize we could really make things simpler or different.
Were there times when you did a clean sheet, or “reboot”, of Cakewalk’s software? SONAR, I suppose was a kind of reboot, right?
Behind the scenes, pieces of the engine, going from Pro Audio 9 to SONAR 1 there were still huge tracts of code behind the scenes that were basically the same. But we definitely took out a clean sheet of paper with the user interface, and behind the scenes pretty big chunks of the engine and code did change significantly to support other technology. For us, coming from DOS to the first Windows versions was a pretty big change. That was an opportunity to rethink some of the feature set and user interface. And then going from those Windows versions of Cakewalk Pro Audio to SONAR was another opportunity. And then doing Project5 was another opportunity.
Thoughts on Piracy
Cakewalk has managed to grow and remain healthy over the last 20 years. But what sorts of challenges have you — and the industry — had to face?
Piracy continues to be a problem for a lot of software companies. And it’s a problem for Cakewalk, as well. Different companies take different approaches. We have tended not to use any copy protection or copy prevention technology, except maybe the most basic serial number [authentication] — nothing like software activation or dongles. And my thinking behind that is that many of those systems get cracked pretty quickly anyway. And they do cost something to add, and they cost tech support issues, and some inconvenience for customers. I’m always concerned about those systems that won’t really prevent the theft, and all they’ll do is make things a little tougher for the people who are paying for the software.
But that doesn’t mean we like people to copy the software. It really comes down to the culture around intellectual property, and establishing your relationship with customers that is about more than just them buying the product, where they can get good support, there is a good community, a good forum for them to interact with you and other customers. So I think if people are buying into a long-term relationship, that’s part of the key to dealing with that issue. And I notice customers really tend to think that way.
For example, I notice some Cubase customers got upset with Steinberg when they suddenly took out DirectX support in an update. I think many of the customers weren’t even using DirectX; it was the sudden nature of it. And why it bothered them is, as a customer you do have this long-term relationship, you’ve invested a lot in how to learn the software, and you want that company to be around and do good things for you. And I think that’s why sometimes people get personally offended if there’s a change like that, that’s something unexpected or unfair. And not to pick on Steinberg — all of us at some time make a mistake like that or do something that we don’t realize how it’ll be received by people. But I think my point is that it is a long-term relationship, and it’s not just about buying a box that has a disc in it.
Do you have a sense of how many people are pirating your software, what the impact is?
I know people sometimes come up with statistics like that. I’m honestly not sure how; it seems like a tricky thing to measure. If you’re using our software, you should pay for it. But I also know what it’s like to be right out of college and feel like I don’t have a lot of money to buy something. I also remember trading CDs — well, actually cassette tapes — with people in college. A year later or three years later I was going on to buy those albums that initially we had traded. I have a little sympathy or empathy with people who casually try something but then go out to buy it — although we do have an official, fully-featured trial version, so there is that very legal way to do it. But I try not to get personally too bent out shape about someone trying something out for a few days.
Looking Forward: Future Technologies, Growth
We’ve talked mostly about the past, but what about, say, the next 20 years? Do you think there’s more potential for growth in music software and creation?
There’s sort of a hierarchy of interest or commitment to music creation. There are a lot of people who have a very casual interest in playing around with making their own music, or putting beats together, or rearranging loops, and I think that can be potentially a pretty big group of people. But the interest and commitment is probably fairly short-term. And from there you kind of go up to increasing levels of enthusiasm to full-time, professionals or full-time amateurs who do this for many, many years. And so I think realistically the number of really committed people is always going to be a certain percentage of the population. That’s my personal theory — but I think that’s also a function of the particular situation of the country and where it is with its economic development. So I think there are at least 2 billion people where that percentage is pretty low today, but ten, twenty years from now will probably be bigger. So I think, from that point of view, the absolute number of people who will be interested in these more committed levels of music creation will definitely grow. But maybe that’s a little longer term — I don’t think it’s 50 years from now, I think it’s [happening already.]
What about growth around the world — will Cakewalk be a part of that? Will there be more homegrown efforts, more bootstrapped Cakewalks in other parts of the world?
I think there probably will be homegrown efforts — actually, I kind of hope so. Not to harp on the piracy issue again, but to the extent a country has its own software industry, that tends to impact the country in general in terms of piracy. Not to pick on Russia, but maybe today Russia is not the best country [in terms of] software piracy. But they have a growing IT industry or software development industry. To the extent that grows, I think that has a good effect on the culture. So I think having home-grown companies is a good thing. We go to a lot of work to localize our software into different languages. SONAR is available in French, German, Spanish, and Japanese. We haven’t done a Chinese language, but I expect at some point we will do that, also.
Another way to deal with this issue is to realize that probably the predominant way you’re going to sell software is part of a package that includes hardware. So sometimes certain cultures don’t value software except as a freebie add-on for hardware, so you can work with that by creating hardware/software solutions. And that’s where our partnership with Roland can be helpful. It’s not the main reason, but it’s kind of one side of that.
What about the Web; how do you see the Web impacting music software, in terms of actually browser delivery or Internet-rich applications?
It’s a really interesting concept — for example, in theory, and I think in practice in a couple of cases already, you could take a music creation application and deliver it as sort of the Web 2.0 application you use from your browser, much as you can do Google Documents instead of Microsoft Word or Excel. I think that’s really interesting, and maybe in future that will be more practical. I think some of the benefits of doing that with text documents and spreadsheets are not necessarily as relevant for music creation. Collaboration can be a big part of music creation, but it’s not the same factor doing spreadhseets or word documents. I think, too, even though the big thing of software synthesis, software effects, people have a lot of gear — so, okay, you have the software running in the web browser, but what about the rest of your studio connections? That also affects the collaboration and portability a little bit. So I can definitely imagine it all working that way, and maybe someday it will. I think, though, it’s more of the dancing bear stage, where the amazing thing is that the bear dances at all, you don’t care that it dances well. But that will probably change.
Splice is cool, Jump Cut for videos is also cool. We were talking before about increasing levels of interest — maybe for that kind of customer, that’s the best way to reach them, or the way they want to interact with things, through a Web-based application. But I think the other element is that — Google Docs, and so on — there’s also a different business model involved.
At the same time, there’s also this trend with Boot Camp and Parallels where maybe — I don’t have any inside information — but I can also imagine three or four or five years from now, many people will be running both Windows and OS X. How they’ll do it, and with what level of explicit support from Apple or Microsoft, I don’t know how that will turn out. But it seems that that’s something people are already doing. Parallels of course is the coolest version on paper, because you can be running them at the same time. On the other hand, I know people on both Mac and Windows who dedicate a machine to be a DAW, and they don’t want a lot of other things running — and they remind me of gamers. A lot of gamers will reboot into a certain configuration to play a game. So I wonder, is it all that horrible to reboot using Boot Camp to run Windows and run SONAR. So I think at this point, that’s all a little bit new, and it tends to be those who are really technology enthusiasts who are playing that. But maybe a platform won’t be as important five years from now as it is today.
That said, it seems the relationship with Microsoft and Windows has been important for Cakewalk, right?
We’ve focused on the Windows platform ever since Windows 3.1, and DOS before that. We really know it top to bottom. We know how to get things done technically; we have good contacts at Microsoft. It’s something we do really well and we want to keep doing. When it comes to music creation tools like SONAR, I think we’re going to continue to focus on the Windows platform. Realistically, porting SONAR to any other platform would be not a very smart business decision because it would take a long time, and what’s at the other end of that tunnel when you come out a few years later? But, when it comes to instruments, for example, as we expanded into doing instruments, right from the start we’ve made things cross-platform. And we love developing for OS X as well as Windows, and we’re committed to doing that. It’s not kind of a religious issue for us, it’s more the practical reality of when it comes to creation and DAW tools, we can do an amazing job on Windows. We can do things that are really solid, very reliable, high performance, and we’ll keep doing that and when it comes to instruments, we’ll obviously be bi-platform.
Do you ever think about what Cakewalk might look like, 20 years from now? (The fortieth anniversary of Cakewalk!) Or how music technology in general might progress that far out?
More in the kind of speculative, casual interest way. I think in music technology — in most technology — looking even five years out is really a long time. So you do it kind of for fun, or to think broadly about what you should do … that’s good. But to get into any detail that gets pretty sketchy pretty quickly.
I think some of the basic metaphors in applications for music creation will be the same — concepts like tracks for example are pretty fundamental. I think how you interact with some of those may be different. A couple of years ago, I know Apple just “invented” multi-touch technology, but a couple of years ago when I saw the other people who invented that I thought that was a really cool thing, and there are companies already implementing that for music. So to be able to grab objects and manipulate them directly and not have to use a mouse is one thing we’ll see more of in the future.
There’s one holy grail left in music technology, too, which is polyphonic pitch detection. I still have this crazy dream that you should be able to take an audio file or a CD and have the software analyze it and do the amazing thing the human brain does which is know that okay these frequencies go together, these don’t. These are one distinct musical entity, they’re not just harmonics — how we actually do that is pretty incredible, and we do it automatically. If a computer could do that, or do bigger pieces of that, I think it’d be really interesting. That would enable a lot of applications, not just remixing but all sorts of interesting applications. Maybe it’s fundamentally impossible to do a hundred percent, but we’re just so far from a hundred percent — to get even close to that would be remarkable.
Thanks, Greg. And here’s to the next twenty years.
We’ll continue to talk to the people behind the tools we use — the creation of music software hasn’t been nearly as well documented as, say, the creation of vintage hardware. So stay tuned! -PK
Other Faces of Cakewalk
I got a behind-the-scenes tour of Cakewalk HQ when I did this interview in August (hence, SONAR 6, though SONAR 7 product art was being finalized by graphics at the time). Many of the music DSP folks are outside Boston, but there’s a huge support, quality assurance, and engineering effort in Boston — not just the marketing and business stuff. You very rarely get to see the faces behind a lot of your software — something I hope we remedy here on CDM in the future, to try to get the creator-user communication more direct. Here are just a few of those folks I ran into.
Jamie O’Connell, Principal Software Engineer.
Jamie is also the co-creator and primary developer of MIDI-OX and MIDI Yoke, which I’d rank as the most important utilities for Windows music, hands down. You don’t have them and you’re a PC user? Go get them right now.
Scott Stepenuck Sr. SQA Engineer (Software Quality Assurance).
Cakewalk really is a dual-platform house. Most cubicles have side-by-side Mac and Windows machines, and by the time I visited at the beginning of August, all the Macs were running Leopard. They also have big, messy piles of documentation and gear, which is I think the sign of good development and quality assurance. (I’m, erm, using my own desk as part of the measure of that.)
Chad Beckwith, Product Manager Flagship Instruments.
Chad manages all of Cakewalk’s top-of-the-line soft synths. We got a chance to chat about tips and tricks with Rapture — expect more on that soon. He also gets the best toys: