Music technology pioneer Geert Bevin talks with us about digital musical expression, prototypes vs. productization and his personal formula for delivering innovative software.
I’m a bit nervous! The surface area of your interests as a human being is insane, plus you already have so many interviews and talks out there!
I’m just a passionate dude doing things he thinks are cool!
Let’s start out with something I’m personally curious about. I live in the EU, where you used to live. You now live in the US, where I used to live. You’ve been there a number of years, what are the cultural differences like?
I’ve worked for US companies since my early 20s. Over the decades, I felt more and more aligned with the American entrepreneurial spirit. Which is a little different to what I experienced in Belgium, where people might be a little bit less gung-ho.
For example, the USPS in the United States. I live up in the Appalachian mountains, Asheville, which is kind of isolated in terms of geography. I can come up with any product I can think of, walk down my driveway, put it in my mailbox, and it ends up in Japan. Just that simple fact made me try a bunch of things that I wouldn’t have tried in Belgium, where the mailman only delivers mail.
I do have a European mindset in terms of vehicles. I try not to have gazillion cars. We have a car and a motorcycle and and I usually use a motorcycle.
I have friends who moved from the US to the EU who found it lacking in terms of social support for their “crazy ventures.”
People are very open here [in the US]. You have a main job and then maybe you have five other things going on. A lot of people do that.
In Belgium, usually you have your house, your family — your job is all you do — and then you chill.
And granted, starting a company in Belgium is a huge deal. You have to get lawyers involved, create this huge deposit and setup separate bank accounts. You have to have an official accountant. It takes months to setup and months to tear down.
The US has an entrepreneurial spirit but it can also have a grind mindset versus the EU where work is just a single aspect of one’s life.
There’s a running joke at Moog at the moment. Once a year, I take a two-week vacation. And always what ends up happening is I just start a new project.
Every time I go into it I’m like, “I’m just going to chill and play video games.” I try to play video games! But then I’m just sitting there and all of a sudden this idea appears and I’m like, “Let’s just try this…”
Are you one of those people where the ideal “vacation” is starting up a cozy side project without deadlines?
Yes to side projects. No to without deadlines. I always set myself deadlines. I’m a firm believer that deadlines drive your projects.
Over the years, I’ve experienced that estimating and driving deliverables from estimation forward always ends up a disaster. Saying, “What does the business need?” or, “What do you, yourself need?” and then working backwards and saying, “Ok, what can I do to support this?” That’s also how I do my personal projects. I always want to get things out there.
As small as a day can be, it’s very important to have people give feedback. Find communities that align with it and don’t go all out. That’s something I’ve seen a lot of people do. They put all this pressure on themselves where they say, “It has to be all the things it can ever be before anyone gets exposed to it.” Which by definition removes feedback. Rolling back or changing direction becomes way more difficult.
I’d rather just have a tidbit. I usually call it the “baby.” The baby project. What is absolutely necessary is for it to have its identity. That’s what I try to work towards.
As soon as it has its identity, I usually throw it out there in some form or fashion. Now it can grow. It can get feedback. It gets its adolescent legs and becomes its own.
How does that intersect with “saying no” to keep scope small. You want the baby to be small, so it’s deliverable. But software plugins have less flexibility. Changing parameter ranges means printing new major versions, etc.
One of the advantages of working at Moog (and the bigger Moog, which is inMusic) is there’s a lot of folks that can be private customers.
I’m just going through it now, working on a new product. We’re at the third milestone. We delivered an installable plugin from the first milestone onwards internally to all the stakeholders. Teams in different brands of inMusic are able to give meaningful feedback. There’s no pressure of keeping backwards compatibility because you can say “This is all throwaway, but please give us your feedback.”
I’m a firm believer in trying things out in the open with open-source. I don’t think that open-source prevents people from purchasing things. There’s a trajectory there where you can innovate, do R&D publicly with people that are open to friction. And then productize it. Because in my experience productization is usually the most amount of work, not the technical research.
In my experience productization is usually the most amount of work, not the technical research.
— Geert Bevin
Productization. That’s a great distinction.
You work on so many different projects, privately and in your day job. Are you hyper-focused on one thing at a time or are you context switching and juggling?
It all starts from scratching my own itch usually. Otherwise I wouldn’t be doing it. Otherwise it’s work. It has to be fun.
I always work on very concrete deliverables. Now, since I have so many projects that are out in the open, I basically iterate through updates.
Do you ever fail?
I consider that I’ve never failed. My first software project deliverable was when I was 14. I’ve always delivered on time and within spec.
[laughs] I love it!
It’s a matter of setting yourself up for success. It goes towards “saying no” like you said earlier. Often I get a lot of friction if people are not used to me being a naysayer about a lot of things. As soon as something triggers my spidey senses… I really trust my gut in many of these things, like, “This is too risky. I can see it blow up any type of schedule.”
What I found to be a very useful tool is to time-box the uncertainty. “Okay, you want this feature? The team can dedicate three days to it. If in three days, we’ve not achieved anything tangible or it has not solved our uncertainty, then we move on.”
This is something I see people do over and over again: speculatively estimating time based on uncertainty and then committing. Basically setting yourself up for failure.
If you don’t know what the impact of a particular task is, then be open about it: “I don’t know. There’s absolutely no way I can guarantee it will be done by this time, but we can work towards it and we’ll see what happens.”
That communicates the expectations, sets you up for success. It eliminates firefighting. It removes stress during your work.
What about the gray areas? Let’s say it’s a personal project, like one of your open-source JUCE apps. You have features you want to build as a dev, and the project manager in you knows when to say no. Do you have features that hang out in a gray area? Do you “decide to decide later” on them?
I usually have x amount of time to do something and I want to get things out. I’d be a little bit more fluffy about what gets into a personal project release. But if I feel that something instead of just flowing out, pushes back and generates stagnation, then I usually extract it and it’s like, “Ok, this is for later.”
This might sound weird but it goes back to Isaac Asimov’s Foundation books, I don’t know if you have read them.
I have read them!
They’re in a Foundation and they’re left to themselves and they need to make these hard decisions, right? The theme that comes up over and over again is: don’t ever force a decision. If something is not ready to be decided upon, it will happen at some point later. And it becomes the obvious decision.
So if something is not obvious and it’s a personal project, then I’ll be like, “It means there’s no answer right now. I’ll just push it out.”
The cool thing is that then you have all these interesting themes that float around and at random times, all of a sudden, that obvious answer will come. And the obvious answer is usually way less effort.
It’s as if part of the job is to identify anxiety and not let the work be driven by it.
Let’s talk about UI and UX. I was using your JUCE app ShowMIDI, opened an UX issue on GitHub and you fixed it the next day. You worked in web before audio. Does some of your aesthetic such as attention to UI detail and testing culture come from your experiences in web?
When I started in the web world, the Apache web server was new.
[laughs]
In those days, there was no mention of full stack development. You develop a thing, right? It doesn’t matter if it’s backend or frontend. Which is how desktop works. You create a product.
And then the web started separating. You’ve got backend and frontend and continuous integration and continuous delivery. You’ve got cloud and web services. You’ve got microservices and infrastructure as code.
It all sort of became, “How can we pull pieces apart as much as possible?” When I started, everything was a monolithic web app. It’s very interesting how things are cycling back to that.
Why are we splitting everything up in web APIs while 95% of it is just a monolithic web app? You’re not Amazon or Netflix or Google. Almost no one is. Chances are so slim you need any of that stuff. So people are cycling back to the “Let’s just build something as a monolithic app.”
My way of working stems from that.
Does this mean you value being a generalist? Do you look for that in other devs in your organization?
I value people being passionate about getting shit to work. Whatever it takes.
I say this to my team: “I don’t care if you built this beautiful function that is not being used.” If somebody is not actually using what you created, it does not exist.
This is an interesting observation I’ve made myself, since I’ve done a few frameworks and developer oriented projects. For those, unless you write documentation for the developers and have example apps that use them, in my mind it does not exist. The realizations you have by putting on another hat — the hat of using your own API and tools — changes the game. Everything becomes different. You thought it would work that way, but now everybody uses it differently.
I don’t value people being generalists. I value people evaluating their work as useful pieces of work that are resulting in something that will be interacted with.
Yeah.
To go back to your last question, I’ve been pushing really hard and it’s been a lot of work the last 8 years at Moog. Everything that my team works on is continuously integrated. We have as many tests as we can. We try to separate unit tests, functional tests, integration tests, system tests.
I do approach all of it as if it’s an enterprise web project, where we have to be thinking about releasing every day. Even if we don’t release every day, everything always has to be stable. You can’t have dangling merge requests that linger for a month.
In your 2017 ADC talk about developing the Moog One with JUCE, you spoke a lot about testing. I really appreciated that, as the web culture of tests and continuous integration is only recently filtering down to plugins. Do you have any new insights since the talk?
Those all still hold true. UIs are notoriously hard to test, just like audio is very hard to test. It all boils down to trying to test for intent and not result.
Unit tests are different. You can test for results specifically. But once you go to higher levels, you gotta be careful when you write tests that you don’t give yourself a maintenance nightmare.
The intent for testing is to set you up for higher velocity, to give you confidence and documentation, give you bravery for refactoring, allow team members to be onboarded easily, making releases less stressful.
Are you allowed to talk about how you test DSP at Moog?
I can’t say specifics, it’s a similar approach to what I said about UI testing. Trying to find heuristics that verify important aspects without requiring your DSP to become immutable.
You have a passion for hardware instruments and controllers. You wrote the first draft of the MIDI Polyphonic Expression (MPE) standard, wrote the firmware for Linnstrument. Software instruments free us from worrying about hardware constraints, but also makes it easy for devs to just throw options and knobs at the screen versus carefully iterating on the design of an instrument. Can you talk a little about that?
It all depends on who your audience is. If your audience is musicians that want to make music, then you have to design a musical instrument. You don’t have to design a sound design platform — that’s not what you’re doing.
If your audience is a sound designer, than your UI/UX will be different. If your audience is a dev, your UI/UX might not even be a graphical UI.
I think the most important thing you can do is allow your audience to be creative. And that includes removing friction.
A skeuomorphic UI makes people not have to wonder what a UI element does. It looks like a knob. It has a range and it turns. You don’t have to explain that, you don’t have to read the manual for it. If you come up with a more appropriate conceptual UI that conveys what your internal model does — if you have to explain how to use the UI, now you’ve created friction.
I think it is exponential friction. Not only do you create friction the first time around, you create friction every single time someone comes back to your product. And people don’t use just one product any more. We’re in the age of people with hundreds of plugins, dozens of instruments.
I’m a big fan of restricting yourself to a sandbox that is appropriate for your user. You put a kid in a sandbox, you give them a shovel and a bucket and they’ll be happy. They’ll be super creative with the shovel in the bucket. If you give them all possible shapes that could ever exist, they’ll just litter the sandbox with stuff. They won’t use all the shapes. They will very likely gravitate back to the bucket and the shovel.
A basic example is the Minimoog Model D. It’s incredibly simple. But at the same time it opens up so much, creatively. There is this desire, driven by tech, to show off prowess and make that front and center, “Look at all these marvelous technical achievements that we’ve been able to create.” If your audience is not technologists that appreciate technical achievements, then I think you didn’t make the right product.
So the product design dictates who your audience will be.
And you can very intentionally do that. It’s one of the reasons why I pushed Roger to make the Linnstrument firmware open-source. It was my condition to work on it. I went through the Eigenharp before and I’d seen how the Continuum was struggling. I thought the only way for this to take off, is to get the technical people on board. The people who are really passionate and want to tinker. And the only way to do that is make it open-source.
By presenting in such a way and not being afraid of some of the complexity of the controller, it dialed into an audience that was open to it and willing to learn. As opposed to having it sit in a random music store where people are like, “MIDI? What are you talking about? Why is this thing not making sound?”
Let’s talk a bit about musical expression. When I sit at my acoustic piano, I can get good at playing my piano. When I move to another piano, it might feel weird for a bit, but the experience translates.
If I play my Prophet-6 synth, I can “get good” at expressing myself with its particular physical keyboard action and sounds. But if I use it as a MIDI controller, it might go through three or four different more layers. The DAW, the software instrument, and then maybe the specific patch may modify the response to a velocity input.
As a player, I don’t often find MIDI velocity or even MPE very translatable when moving across controllers and software. Is the answer that good digital musical expression requires an all-in-one integrated hardware-software solution like the Linnstrument or the Osmose? Is there any hope for a cheap controllers hooked up to random software?
Such a number of things here. The concept of a musical instrument has been neglected by many people that approach things with controllers and software. One of the things you hint at is very true: In order to feel inspired and have that creative feedback loop, you need to have a personal connection to everything that is going on. Additional layers make things harder.
Yeah, I need to feel good at playing the thing!
Right! Overall, I think we’re going in the right direction, but we still deal with all these layers that fight each other. They make it way harder to have “one experience” that vibes for you. So, in that sense, Osmose and Continuum are great examples of integrated solutions that you can treat as an instrument. It’s also one of the reasons why Roger has created sounds to use with Linnstrument.
Moog supported MPE since I started working there. With Mariana, our latest synth, it’s consciously built into many of the presets and it’s been propagated through the actual sound design. I think over time we’ll get closer to that.
I think there’s a really big problem with velocity. Velocity is artificial. There’s no traditional instrument where your initial impact is set in stone for the whole duration. If you hit a string on the guitar too hard, you can always dampen it a little. In many instruments, you have a way to interact continuously with whatever impulse you created. The main frustrating aspect in my experience with the MIDI 1.0 approach is once you hit it, what now? There’s no way to self-correct. Humans are really really good at self-correcting, when given the opportunity.
MPE is the first way of doing that with electronic musical instruments. When implemented well, people get the opportunity to have three dimensions of continuous interaction. If your controller and transport protocol is fast enough, you can just use pressure as velocity.
I think MPE has started a conversation. I can’t believe how well it has taken off. I remember 15 years ago when everyone was calling me crazy. I was knocking on everyone’s doors, “You guys, there’s this opportunity. Why are we not doing this? It’s not rocket science!”
You knocked on Moog’s door, too. Isn’t that how you ended up working for them?
Yes. Look back at how sprawling this has become — how many brands and products are adopting it and experimenting with it — examples like the Osmose pop up. This has taken decades of experience and people trying things to come up with a novel instrument that feels like an instrument. It needed all of that. And it will continue.
We’re comparing against, like what you said, a piano or a guitar — instruments that had centuries of refinement before actually becoming commonplace. I think people tend to forget that, to not give enough rope to any of the product creators out there. Without going through the lifecycle of experiences and user feedback, you cannot get to that refinement.
That is why I often try to put in little pieces of experiences out there, like the work I’ve been doing with the Vision Pro. You can only start asking the question of what it means to create music in the spatial computing realm by trying it out. None of it is intended to be final. All of it is just starting the conversation.
I love that. I walk away from this feeling like I’ve been quite impatient. Because you’re right, we’re right in the middle of very exciting and fast changing product development.
It’s remarkable that something like the Osmose has come along merely years after the publication of the MPE spec.
I think it’s something to be very proud of. You’ve described it as “unblocking the status quo” or “getting out of the 80s” and I think that’s correct.
I’m building an additive synth in JUCE with continuous control of volume and pitch of each harmonic. Got any interesting MPE ideas I should do with it? What should I build for you? [laughs]
I personally think you can’t reason about that.
You mean I’ll need to just iterate?
It’s like writing about dancing. You can’t write about dancing, you have to dance. You have to experience someone’s dance. I think MPE and synthesis is the same thing. When you think about it ahead of time it’s most definitely going to be wrong and not the right feeling.
Sit with your sound engine and discover. Do weird shit.
Wise words. That’s the answer I’d want you to give!
Geert was interviewed by Sudara, who is building an additive synth with JUCE.
Have comments on this interview? Ideas for who we should talk to next? Let us know on the JUCE forum.