Starting a business with a good friend can be risky, but there’s nothing like it when it works out. The JUCE team talks with Gustav Scholda (pictured left) and James Swift about prioritizing the creative flow state, CI-as-UX, and their success on the iOS platform.
How did you guys get started?
Gustav: Basically it started when I was introduced to the Kyma system. It’s kind of similar to Max MSP. You can connect things with each other and build your own effects. In the beginning, I was interested in the morphing and spectral modifications it can do. It has really nice spectral analysis and re-synthesis.
I started to work with Cristian Vogel, selling sounds for the Kyma ecosystem. But at some point we were like, “Ok, the Kyma community is quite small.” I was thinking maybe we should start learning C++ and doing the whole thing as a VST and try to sell that. Because the community is way bigger — like a hundred times bigger or a thousand times bigger.

So then I started on my own and learned C++ and discovered JUCE really quickly of course. I started working with Tonsturm in Cologne and made the first two products with them, FRQShift and SPCTRL EQ. I did the whole DSP and audio engine part.
I wanted to be fast. I wanted to make more products. That’s why I came up with the idea to do everything on my own. James was key to that, because I knew I couldn’t do it alone. I definitely needed someone else.
Why couldn’t you do it alone?
Gustav: It’s just too much work. I guess you know what I’m talking about.
[laughs] What do you mean? I’m fast! [insert the thousand-yard stare of a solo dev]
Gustav: Also, he’s a way more experienced programmer than me. I was fine with DSP stuff and so on. I’m good with Maths. I studied Tonmeister, so I was fine with all the music theory and everything. But programming was still kind of new to me. James came from a different direction: a programmer who likes to do music as a hobby.
James: The first instances of that was on my Commodore 64 when I was 13 or 12, writing little programs in BASIC to do sounds and tones. And then you started on your idea of “I want to learn C++” so I helped you a bit along the way.
Gustav: Yeah, questions you can’t find on Stack Overflow.
Like, “Why the heck is the entire ecosystem like this?”
Gustav: [laughs] Exactly! “What is compiled?”
James: I just steered him away from the dragons and towards some modicum of sanity in the C++ world. It’s a gigantic language and ecosystem and you don’t need all of it.
How did you guys figure out who is responsible for what? Who is doing UI, who is doing CI [Continuous Integration]?
Gustav: It was clear that I’m not so much into UI. So from the beginning it was clear that James will take care of UI stuff. Also the CI build system was something that I was not really comfortable with.
James: I have 20 years experience understanding how it can go wrong. How it can end up slowing you down as a developer. Obviously Gustav is the DSP wizard, but I have all the experience in “oh yeah, this is going to bog you down, this is going to bite you a year later and you’ll never get another plugin out.” The phrase is programming in the large, right?
Gustav, you were happily using JUCE on your own as well, though?
Gustav: Yes. I actually love C++ because it’s so clear.
It is?!
James: Stockholm syndrome, I say!
Gustav: For coding DSP, it’s perfect! In the past I had problems with scripting languages like CopyTalk which is a smalltalk variant used in the Kyma system. I could not define if something is a float or double.
James: We also did it right from the very beginning. We are very strict programmers. We have warnings at maximum, warnings as errors. If we turn anything off, we talk about it. We use linters. We use continuous integration. We have test suites.
Ok, let’s dig into some detail. When you’re building a company that sells plugins, you usually have to reinvent some wheels, for example a preset system. Did you build these things up front with your first product?
Gustav: Yes. We developed it with our first product. We took a year just working on the basics. The preset system, the header, menus, the basic structure the plugin is living upon.
James: But there was a view to it being for more than just one plugin.

Are those things JUCE modules?
James: No, it’s a monorepo and we don’t use any static libraries. It’s one big codebase [for all products]. With CI, I have a particular philosophy. My view is that it’s replacing you. It’s a “robot you.” It should be running your scripts. We use Ruby because it’s easy to port. It works everywhere.
Those scripts then call CMake, generate projects for the target. It joins up our core library. Our core library isn’t a static library, just a directory. Everything is very cleanly namespaced.
Gustav: And a new plugin or project is just a few files with some resources. An editor and the processor.
How do you decide “Hey, I want to do a new product.” What is that motivated by?
Gustav: In the beginning I knew I wanted to do MagicDelay first. I had coded my own spectral analysis and re-synthesis. I knew I had to grab people by the hand and show them that spectral world with some familiar effect. I didn’t want to start with MagicBlur, for example, because a spectral blur effect is something that is very exotic.
So you have a series of plugins that are based on what you can do per-frequency?
Gustav: Exactly, that’s the Magic series. That’s what it’s about.
So what about now, a few years in? I guess business sustainability is a topic?
Gustav: Yes of course. The Quantum series was basically driven a little bit by business. We realized this modulation system we built is really handy. And we don’t need to reinvent the wheel or come up with a crazy new effects. We can build standard effects and combine them with our modulation system.

So the Quantum series came out of a feature in the Magic series that you extracted and built around?
Gustav: Exactly. Also our Magic series is, I wouldn’t say expensive, but on the iOS market people said “Oh, that’s quite expensive.” And we were like, “Okay, we should have a separate product line that is cheaper for people to get into.”
James: When we released our free MIDI modulation tool MMM, the number of users exploded and we got a lot more feedback, like, “Oh my god, this is a great modulation system.” Previously we thought, “Who needs another delay?” But then we thought, “We can actually make a new delay that is different”. Even within the delay section, we did take care to bring something new to that as well.
Gustav: I always try to not make super standard bread and butter effects. There are some features which I think are useful, like a dB per second control for the feedback. Or having quintuplets for delay times, which are used in dubstep stuff and I don’t see them elsewhere.
Are you prototyping outside of products?
Gustav: I do have some kind of sandbox environment where I can just bring up some controls and basically hook up any DSP code that I want. That’s so fast I don’t need to do that in a different environment actually.
You are doing that in a JUCE environment?
Gustav: Yeah, just in code already. Just make a little UI that doesn’t need to be beautiful, but the functionality is there.
With JUCE default look and feels?
Gustav: Basically! I mean, it already has our preset system built in. I already have the modulation as well, which is really nice for a testing environment. Because very often you want to listen to how something sounds when it’s changed.
James: We also can’t forget the amount of times we go to gigs and meet professional musicians, from sound engineers to on-stage performers. We talk about our stuff with them and in a weird way those conversations percolate through to ideas.
Gustav: One thing we both really like to pay attention to in the user story kind of way is we don’t want to break creative flow. That’s a kind of a dogma we put on ourselves. Let’s say right now I had the idea to modulate that with an LFO. It should be fast enough and it should be easy enough so I don’t need to think about anything else. So I don’t need to switch to technician mode and suddenly type in some values for some LFO.
So you are both into user experience?
Gustav: Very much, actually! I want to make the complicated things not complicated.
James: After we got a few plugins out, we were humbled a bit at some bad decisions and reversed them. As we mentioned, we put a lot of effort upfront into our CI. We were able to fix things quickly and put out updates. This is part of thinking about the user experience. User experience isn’t all about making nice buttons that are easy to use. It’s thinking about how quickly you can react to a frustration of the user. I would say people should build in about 10% of their time in maintaining their CI system.
It can be hard to prioritize that, especially as a solo developer. I just spent a whole day last week on CI stuff. This broke, that almost broke, this will break and needs updating. Before I know it, the whole day is gone.
Gustav: Oh, sure.
James: You’ve been really generous about writing about your troubles as well. I also try to jump onto the JUCE forum and try to help people. I figured out that API privacy thing eventually and posted the solution.
Oh, right what was that all about?
James: It was just hard to get it to fit into CMake.
Gustav: There was some change of policy on the App Store.
James: You do a lot of work for other people. I appreciate all the people that do that sort of stuff.
The community is pretty small and we’ve all benefitted from random forum posts where people actually post the answer! It’s so valuable.
James: It’s a horrible thing to go and ask for help, figure it out and then not go back to tell everybody how you solved it!
Gustav: Or just saying “Thanks, I solved it.”
That’s evil! If the JUCE forum exploded and was data corrupted it would definitely be a blow to plugin development everywhere. Let’s talk about iOS a bit. You’ve had positive experiences there?
Gustav: Definitely.
James: We were quite lucky that from the beginning, that first year, we thought that touch might be a thing important to us in the future. Not thinking about iOS, but Gustav’s laptop is a touch screen. So we designed everything with that in mind too. It’s very easy for people to use, even on a tiny iPhone. If you’ve developed an app for desktop and it’s all about tiny little clicks and mouse clicks…
Yeah, right clicks.
Gustav: Exactly, no right clicks. I mean, it took us two to three months to be able to release iOS apps. It was a lot of work. Now we just code one plugin, and deploy it to iOS as well. It doesn’t need extra touches. There’s really just a few macros in our code regarding if it’s iOS or not.
James: We have a motion modulation source on iOS. And on desktop we’ve got the camera because we can’t use it on iOS. There’s some tiny differences.

Any advice to other devs wanting to ship on iOS? Do you think there’s a product angle that makes your stuff compatible with the market?
James: Great question!
Gustav: I still think the iOS market is not overcrowded with plugins. I still feel people are hungry for more.
What’s your secret to succeeding on the platform?
Gustav: [laughs] Secret! If I knew…
James: Make sure that your very first preset is brilliant. We just got to make sure that when they drop it in, whatever source is coming in, it initially sounds really good. We got a lot of praise from reviewers for having good presets. We pay artists to make them for us, and so they take care. Don’t do anything that there’s already a king of out there. Try and do something new.
Gustav: Don’t do an EQ that looks like FabFilter, for example.
James: There’s no need to do any more spectrum delays. [laughs]
Is deploying to the platform financially worth it?
Gustav: Yes. Because they’re only taking 15% if you are in the Small Business Program.
James: Make sure you apply to that before you release your first plugin. It takes a couple of months for it to go through! [laughs].
What about as an overall percentage of your revenue? Is it worth it from a business standpoint?
Gustav: At the moment, I think we’re making a little bit more money on iOS than desktop. Maybe also because it’s less friction. Buying stuff on iOS is super easy.
And this is for products that are priced at like $20-40?
Gustav: Yeah, we always do 50% of the desktop price for the iOS product.
James: Our rationale was users can’t resell it. Also it’s not like those people are working in large studios and throwing tons of money at stuff, except the iPad itself. I would love for some of those iOS purchasers to have a little more empathy for us when they complain about the prices. “Hey guys, this stuff is super cheap, you don’t know how cheap it is.”
In a way, the reduced friction of the platform causes a disconnect where developers are spending 2-3 years to put out a 5 dollar plugin.
James: They’ve got families, they’ve got mouths to feed.
As a consumer, you don’t see any of that! You just see “Buy $4.99” and then it doesn’t do exactly what you wanted it to do! [laughs]
James: The Audiobus [forum] people have been super with us. When we first came out, we were actually higher priced. We’ve taken it down a small bit. People defended us on there. There were people saying horrible things about our pricing and then other people came to our rescue.
Gustav: And we were also talking about it like, “If we trigger that kind of discussion and people defend us and get into a forum fight and we don’t even participate, I think we made the price just right.”
James: We would give it away free if we could figure out a way to live from it, but we can’t.
Gustav: If you’re only into money, don’t develop audio plugins. Do DSP algorithms for finance trading stuff.
James: All we want to do is get by and enjoy what we’re doing. At the end of the day, I’ve enjoyed every single day of this.
Gustav: Yeah, me too.
James: I mean, I’ve screamed and raged and almost threw my laptop out the window due to a couple of shenanigans. But other than that, it’s been pretty damn good.
Sudara rode a U-Bahn and then a tram to interview Gustav and James at their Vienna, Austria office.
Have comments on this interview? Ideas for who we should talk to next? Let us know on the JUCE forum.
