Why would anybody start writing a DAW in 2005?
JF: It grew out of frustration with the existing software that I'd tried to use. My career is as a programmer, but a few years before [Reaper], I started playing music for fun. Christophe turned me on to Vegas — I think it was Vegas 4.0. I used it for a while, and got a little annoyed with some of the limitations it had for audio. At a certain point I decided that I would like to have control over the environment I would work in to make music, and I started making my own, just for fun. It kinda went from there.
Was it just you at the time?
JF: Initially, and Christophe joined in 2006.
I remember reading about Reaper back then. The product was evolving very quickly.
JF: We were pretty productive. If you look back at what we've done in the last four years, given the number of people involved (which at this point is up to three) we've definitely come a long way.
Other DAW companies are easily 10, if not 100, times as big as yours.
JF: Yeah. Our overhead is really low, and because we're making software, we don't have per-unit costs. We can take the time and do things right. We don't have a big machine that we need to support and we don't ever need to push out new releases in order to increase revenue. We own the company, so we're only accountable to ourselves. In that sense we don't compromise the product or the way we treat users in order to meet some arbitrary goal. There's also an emphasis on keeping it so we don't have to deal with additional bullshit, which is easier when you keep things small. As a developer, being able to build everything quickly and easily is important. Being able to update the website and post builds online for people is important. If our program was a gigabyte [in size], say we included a ton of samples, a lot of things wouldn't be possible. This is a good example — in software development, there's something called QA, which is quality assurance. The big company process is that you have elaborate QA processes where you test all kinds of different things for every release. It's somewhat effective, but in software, there's just so much complexity, so many states things can be in, that anyone who thinks QA is even north of 50 percent effective is delusional. You are never going to come close to getting all these states tested. So you try, and you waste a ton of time and effort testing things, which then slows down your release cycle, and slows down development as a result. It ends up decreasing the efficiency of the process for some margin level of effectiveness, and it's mostly a cover your ass sort of measure. We obviously do some internal QA, but for the vast majority we rely on a group of testers who test builds when we add new functionality.
So you have users who are willing to be ongoing beta testers?
JF: Users who are psyched to be using a latest and greatest feature and to give feedback suggesting how things should be. It's open — anyone who wants to do it can. Generally speaking, it is more effective than any QA process I've ever seen in a corporate environment, and it's much more efficient.
A big aspect of Reaper seems to be your relationship with your users, versus the way users are probably accustomed to being treated by large companies.
JF: That's something that we've felt strongly about from the beginning, and it's something I felt when I started my first company — which I then lost control of and sold.
I saw a good example on the Reaper forums. Someone was talking about UI in the Mac port being un- responsive. You said, "Hey, I'm not seeing this. Let's talk about it," and there was some back and forth. Then a few days later, you posted, "Here's a patch. We rewrote a ton of the Mac UI painting code," and everyone was like, "That fixed it all. Thanks!"
JF: Yeah, that is not unusual.
That is unusual.
JF: [laughs] Fair enough. I think our users appreciate that, and as a result we have a fantastic user forum. There are so many people on there who are really awesome. It's something you don't see very often on the Internet. Newbies come in with questions and people help them out. Our new contractor was saying that in a few weeks, the newbie that got help then ends up helping someone else out.
Do you have any idea how many people are using Reaper?
JF: It's hard to quantify. We've tracked downloads at different times. I think the last time we checked, we guessed maybe a hundred thousand people really used it on a day-to-day basis.
The general consensus seems to be that these days all DAWs are roughly equivalent. Would you say that's true about Reaper?
JF: "In what way?" would be the question. You could say they're equivalent in terms of their very basic capabilities. You could say they all mix things to sound roughly the same. That's fair. If something doesn't mix things the same as other software, then
it's either a bug or a feature, depending on how you want to market it. I wouldn't say they're the same, because Reaper does a lot of things that no other software really does at all.
Such as?
JF: The biggest one that I am continually blown away by is that no other software supports vari-speed recording or playback.
I've noticed that!
JF: It's 2010! Analog tape machines did that before I was born! What's up with that? We have really good routing flexibility. You can create entire complex setups. It's like having a patchbay and a ton of effects that you can wire any way you want. Even within each track you can have 64 channels, so you can load up a bunch of effects and route the outputs of one to the inputs of other and that sort of thing.
CT: When you asked, "Why create a DAW in 2005?" — that is why. We can design in a new way.
So the ability to start your architecture from ground zero, with no cruft.
JF: It's a huge advantage. If we had to write for hardware 10 years ago, let alone 20 — a lot of stuff we can do now, we wouldn't have been able to do. It wouldn't make sense.
Can you talk about the Mac version of Reaper?
JF: We started out developing for Windows, but pretty early on it was clear that people wanted a Mac version. So we've been working on it. It was originally posted to the website as a beta in October 2008, and we dropped the beta tag in March. It's constantly being improved, and we're at the point now where it's almost at parity [with the Windows version]. Part of the problem is Apple's developer documentation. They break things in new versions of the OS, and add new features that make things faster but that aren't supported in the old versions. Programming for the Mac is pretty much a nightmare.
Reaper has its own plug-in scripting language. That's neat.
JF: The language is called JS, which is confusingly short for JesuSonic — that's a previous live-performance project we made. Then ReaJS is a VST plug-in we make available that allows JS scripts to run in any Windows VST host. The nice thing about JS is that you can write it on the fly. So if you are a plug-in developer and you want to try out some algorithms, you can do it without this cycle of quit your host, compile your code, run the host and try it out — this long process.
Are these plug-ins performant? Are the stock Reaper plug-ins written using ReaJS?
JF: They're not as fast as native code. They're probably half as fast or so. But people have a lot of processing power these days. There are a lot of included plug-ins that are written in JS, however things like ReaComp and ReaEQ are not.
What are other people doing with JS?
JF: The thing is that the scripts people write are text files. So essentially everything you write is open source. What's really great is that even if you have very limited programming skills, you can customize something that someone else has written to meet a particular need. That's especially useful for things like MIDI where you're like, "I want to make something that transposes these notes, but not these notes." That is really straightforward.
Reaper has no copy protection. Would you recommend that to other software vendors?
JF: Absolutely. Copy protection is terrible. It only ever really impacts people who have paid you money. Similar to the QA discussion, no copy protection will be foolproof forever. It's war that you fight, but you can never win. What you'll do is you'll end up spending a lot of money to do that, or a lot of engineering resources that could be better spent on other things, while making paying users jump through hoops. It's not a good way to run a business.
For a user all you have to do is forget your dongle for one session...
CT: ...and you're fucked. JF: The lack of copy protection drives a lot of our design. We have a fully featured demo. You can use Reaper for 30 days to evaluate it, but at the end of those 30 days it doesn't actually stop working — you start violating the license agreement at that point. If your computer dies and you're going to record somewhere, and you need to install Reaper and don't have your registration email with you, you don't have to worry, "Is it gonna work?" It's always gonna work.
Reaper's price model is unusual.
JF: Yeah, and it's been successful. We have two prices: One for businesses that earn over $20,000 a year. They pay one license fee, which is $225. Then everyone else — individual users, hobbyists, non-profits, if you have a small business on the side, like you're recording bands and charging them money, but you don't make more than 20 grand a year — you pay $60. Licenses are valid through two major version numbers, so if you buy a license now — we're at 3.66 — you get all of 3.x and 4.x.
What's next for Reaper?
JF: We have Reaper 4.0 coming up, probably by the end of the year. It's all secret though.
CT: It's gonna be awesome. It breaks our heart not to talk about it because it's really big.
JF: I don't think we've announced any of the [features], but I will say that the way we develop things is to not rewrite things. Generally speaking, rewriting things is a big waste of time. Rewriting individual parts is alright, but you have to be super careful of what you redo, because any piece you look at, there's going to be more than you think is there. We're going to add new capabilities. For people who use the current version of Reaper and like it, it'll be pretty much the same except it'll do more. That's the way we do it. It's very incremental.
