Eyal Amir from Modalics

Eyal Amir is a talented performer, a fountain of JUCE and C++ knowledge and one half of the fledgeling indie plugin company Modalics.

Eyal speaks with the JUCE team, one year into doing business.

You just launched 2 new plugins, MINDst and Bitfuzzer. That makes 4 in your first year of doing business, which is insane. I want to know where your brain is at right now: Are you drowning in stress? Are you pretty chill?

Running a company is stressful in general, because even when things are going well, you are always thinking "Hey, what's the next thing that I have to do?"

And there's all of this company management stuff. I'm more used to being a developer. So the development isn't really stressing me out, but the business stuff — now we're starting to hire freelancers to do things, so we have to manage them — that's kind of complicated.

That's nothing to do with product making. It's just Or (my business partner) and I not having that much experience managing something on this scale.

The pace is insane! I'm curious how that shapes the scope of the plugins, the products themselves. Does the release strategy drive product scope for you guys?

I wouldn't say that the schedule drives the product, but I would say we're very mindful of the fact that if you don't get anything out in some period of time, that's a problem for us, as a business.

But also, something we've learned in our music career, is that sometimes if you work too much on a song or an album or something, it kind of loses the freshness.

I guess framed in terms of perfectionism: it can prevent you from practicing the full cycle of development and shipping.

Yeah, and we also feel like it takes a little while (with a product released) to even get an idea of what is the most important thing about the product. It's not always what we think it is. Like, we have beta testers, and they'll give feedback, but it's not always equivalent to what you get from people in the actual world on the outside.

MINDst is something we've been developing for about a year. But we took steps away from it to do other things. We took a break to do EON Arp, our arpeggiator and then we took a break from it to the iPad version of Beat Scholar.

That was not such a good process for us in the sense that it took too long. We've felt close to the release, stuck in this, for way too much time. And ideally, we'd like to make the cycle shorter.

What happens is you start to develop some distance from the core because you're always working on this menu, or a loading presets thing or something to do with copy protection. And then you wake up one day and it's been like two months since I've done anything related to the audio! Is it good? I don't know because I'm not testing it, right? I'm just working on these menus and presets and stuff. So it's something we're trying to be mindful of.

I really like that idea: the "core" of the product. Do you have any hacks? I guess you are a two person team, so while one of you is on some tangent, the other can keep the fire going?

Yeah, but both of us go on tangents the same way. It's very difficult for us to stay focused on the thing we need to do, but we also have periodic talks about it.

One of the things we liked about our latest release, which is BitFuzzer, a distortion thing, was that it was slightly more than a week from idea to a finished product. That was one of the goals we set up.

We were like, okay, we've been working for a year on this other thing. One of the good things in the way that we work is that we developed all these libraries already. So we've had all these systems in place to make this quick. Like, we didn't have to write a preset system. We didn't have to write the undo system. This was like a way for us to test that we've actually done correctly, in terms of connecting visual assets to the UI and all kinds of things.

That's amazing. It's like a true end-to-end test of not only your entire dev system, but the whole product pipeline. Speaking of, you co-founded Modalics with Or. You helped him get more hands-on with code, in part by building some tools to iterate UI, specifically hot reloading. How critical is that piece in your pipeline?

That's something we talk a lot about, because our ability to work quickly is really crucial for us. If we don't develop these abilities over time then we're going to need to hire a ton of programmers to do really mundane things, which is something that I've seen in other companies that I work for. You hire these engineers and then they end up moving pixels around, because it's difficult to do.

We try to identify what would be really bad if we put them in C++, like the pixel position of something. But we also have decided that it's pragmatic to say if you need an if statement, just go to C++ and write the if statement instead of writing bindings to the other language.

So it's about separation of data (pixel numbers, colors) and code (business logic). Figuring out where that separation is best for you, your iteration speed, and the skill sets you both have.

I also try to measure time that I actually save.

Because when you work on JavaScript code or something, you save on compilation but then you need to debug the actual thing. So, to me, that's the same time. And I'd rather debug it during compilation time (it doesn't compile, you have to fix the type) than debug it at runtime.

In your opinion, should/would/could JUCE offer something like hot reload? Is it something that belongs in the framework?

I dunno. This is a discussion that happens a lot on the forum. My personal opinion is that I would like JUCE to do what they are best at. I'm not saying this specific thing is not something they could do really well. But offering an API like this, that developers actually want to use...

For example, if we take our API and offer it publicly, I would need to add a bunch of features to it that people will request. The way it works for us, is I'm trusting that the subset of features that we actually use is in this. But if I had to support *any* UI thing, if I had to do the full CSS spec or something...

As someone who has shipped 4 plugins in one year, what do you consider worthwhile testing?

I'm not an expert in unit tests. This is a relatively new thing for me. We do unit tests for a lot of things in our library. Especially if it's very clean things. For example, we have the serializing library. So we test that, that's something that has very clear boundaries. We test some DSP stuff, since that's just math, that's very easy to test. For example, MINDst drums has all of this logic of how it generates reactive articulations, so that's testable.

So we're trying to test things that are somewhat complicated but also have very clear end-to-end goals. It's not ideal, I would have loved to test more things. Sometimes I've done unit tests that haven't worked out, just because I'm not as experienced in the technique. Sometimes I would do unit tests where every time I would change the code the test would break, so I feel like I'm not testing the right thing.

You made the decision to found your business on JUCE. Was it always going to be JUCE or were there other candidates along the way?

I like JUCE and I've used it before we started Modalics. I've used it on a few commercial projects for other companies.

I don't know if there are a lot of other alternatives that are good. I know there's VST GUI, I don't know what the state of it is now. I know there are other options if I want to use just the plugin wrappers, like the VST3 SDK or CLAP, but they don't offer what JUCE is offering really. iPlug2 is another one. There's all these frameworks, but I would still need a solution for file system and window opening and layout. Other than VST GUI, I'm not sure there's an actual alternative other than building my own from scratch, which would be a big undertaking.

What's your take on WebViews? They are getting some love in JUCE 8...

I like the fact they exist. I'm using the older browser windows quite a lot to show something from the manuals or the website. So it's definitely useful that JUCE would offer a way to do some more JavaScript web view for a full UI of a plugin.

I'm happy they are doing this, but I'm cautious. I want to see somebody do this first. When I first saw companies like Output use WebViews, they only used it for areas of the plugin not interacting with audio, like sample browsing.

What do you want JUCE to do over the next couple of years? What do you want JUCE 8 or 9 to focus on?

There's a few things that I think would be cool. One of them we ran into is mobile features. When we did the iPad app, there's a lot of native things that are missing in JUCE. Some of it we've had to write manual Objective-C. And some of it was just not possible. So it would be nice if mobile would get a much higher priority.

I would want to see the JUCE team be very connected to either the people working at Steinberg or Apple or just be on top of whatever news is happening. A new feature comes out in VST3 and I'd want to see it in JUCE like tomorrow. [Editors note: The JUCE team regularly work with all of the plug-in SDK vendors behind the scenes to keep everything operating smoothly. Look out for an exciting development along those lines that might make it into the initial release of JUCE 8!]

Lets talk about iOS a bit more. You ported Beat Scholar to the platform. What was the experience like? Was it a couple weeks of work? Was it a big ordeal? Was it worth it?

That is a loaded questions! [laughs]

It was a big project for us, not because of the Objective-C stuff, but because we had to redesign the app for touch. We had to do a lot of work so it would look and feel normal on iPad. We very quickly found the regular UI just doesn't work from a UX point of view. There's a lot of things we had to do ourselves because JUCE doesn't do stuff like long press and swipe. Like, a lot of gestures don't exist.

And was it worth it for you guys? Was it a good investment?

The good thing about it is it opened us up for a lot of audiences that are not usually plugin buyers. It's hard to say. It's just been a few months, so I can't say in the grand scheme of things if it was good or not.

Commercially, I think I would have liked to stay focused on the PC and Mac. But from a brand perspective it did get us to a lot of places where we have not been before. And that is also something important for us.

Going forward, when you're designing UIs does that mean you are always keeping touch in mind — or was it a one-off with Beat Scholar?

We have it in mind, but we are aware that some of our stuff is not going to work on touch. I mean, they're going to work on a basic level, but not at a deeper interaction level.

I remember the first thing we did with Beat Scholar was compile to iPad, and you know, it worked? It was ok. It didn't crash or anything. But then you start to realize there's all these more complicated things, especially when you talk about loading files on the iPad, that's different than on the PC. If you want to share files between the standalone and the AUV3, it's different. Things are different in the way the system works.

You've had a huge positive impact on people in the JUCE community, whether it be on the forums or discord. You've been a very helpful presence, contributing to open source, showing people how you solved things. What's the motivation for that connection to the community, to really giving back? Is it related at all to your business?

It's nothing to do with business. I got into the JUCE community way before the business existed, just because I was learning it and making products with it as a freelancer for quite a few companies.

All these people in the community, like you, like Daniel, like Reuben from the JUCE team, all these people who were really active on the Discord, on the forum — I've learned from all these people. This is how I developed my skills. This was just out of the interest that I still have in being a better programmer, knowing JUCE better, knowing C++ better. I just did it as part of the process

Something I learned in my music days, when I was a full-time musician, was that if you teach somebody something, then this is where you really have to understand it, right? And sometimes (this happened a lot of times) I would go to answer somebody on a question where I was sure I had the answer. I'd go and type it on Compiler Explorer or something and I'm like "Oh no, I don't know what I'm talking about. What is this?" And that's how I learned. That's how I get better.

I feel like you are one of those devs with a lot of both depth and breadth. Looking at your portfolio is intimidating! Let's say you are a newcomer to JUCE, what would you suggest people focus on. Do they need to become Eyal?

Well, they don't need to become me! I used to go to schools and talk to people in high school and they would ask me this question, like "How do I get your career?" or something. Why would you want my career? You can make a much better career! You're the next generation! You don't have to be like the old people, like me, you know [laughs].

What does a better career look like?

There's a much better career! So many people have done so much better than me in both programming and music. The way I see this is that you have to focus on what drives you, because all I did was just follow my passions and my interests. They're not necessarily your passions and interests.

I definitely learned from my first jobs as a developer, when I worked for Waves and for Polyverse. I was just a programmer studying with these more senior programmers. So that helped, in terms of skill.

When I was at Waves, there was Jeff McClintock who worked there. He taught me a lot of things, a lot of techniques and a lot of stuff. Sometimes directly, but sometimes just by you know, I would look at his code and see why he did this or why he did that and trying to debug and understand that.

Your history is in music performance. You have the heart of a performer. How does that influence your approach to plugin making. Are you making plugins for yourself?

Kind of! Yeah! I'm making plugins for myself. I'm trying to make plugins that look at the world or at music, the way I would look at music.

A lot of the way these plugins work — and this is true for Beat Scholar, it's true for EonArp — they're things that were ideas and conversations that myself and people I work with had. Those conversations would happen when we're writing music, maybe when we're mixing music. A lot of the Beat Scholar UI is stuff we would talk about in band rehearsals.

And then when we come to plugin design, we're like, "Okay, it's this topic that you and I have talked about for many years. Let's find a way to put it on screen." We know that we have some different concepts about music and we know that if we make them clear enough for the user in terms of the UI and the overall experience of the plugin that would connect them to our experiences.

So you are encoding your outlook on music and your process of music making into these products.

Yeah, for sure.


Check out Eyal's company Modalics. Eyal was interviewed by Sudara from melatonin.dev.

Have comments on this interview? Ideas for who we should talk to next? Let us know on the JUCE forum

More "Made With JUCE"

linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram