Clarifying Some Things, and What I'm Doing Now

Published on:

Table of Contents

Preface

Welp, apparently one of my previous posts DAW Frontend Development Struggles is trending on Hacker News and the Rust subreddit. Couldn't have come at a more awkward time.

I want to take this time to clarify some things, as well as what my current plans for Meadowlark are. Some of my opinions have changed somewhat since that post.

Clarifications

I want to clarify that I do think a fully-featured GUI library in Rust is possible, it's just that it's still a few years away.

Also I want to state that my complications have more to do with the fact that I'm writing a complicated DAW GUI and not a typical application. Existing Rust GUI libraries are already (mostly) competent at this.

And yeah, I was maybe a bit quick to dismiss slint and makepad in my post. I now have a different reason for not going with those which I'll explain below, but I don't want to downplay the potential of these projects (and also projects like vizia and iced).

I now think declarative is probably possible to use for something as complex as a DAW (although it's still more cumbersome IMO). Immediate mode might also work if executed correctly.

The xilem architecture also seems very promising in solving a lot of the problems that a GUI library in Rust has. But of course it's just an experiment at the moment.

Also my opinion on the importance of damage-tracking has changed somewhat. I no longer think it's that important in the advent of modern GPUs. But I do still think that more consideration should be given to minimizing the work being done on the GPU.

Sparking Discussion on Rust GUIs

That being said, I think the original opinions I had in my previous post illustrate an important point.

It goes to show that a lot of work and careful considerations are needed if we ever want a truly general purpose Rust GUI toolkit to take over. I'm sure I'm not the only one who has been frustrated by the state of the Rust GUI ecosystem.

GUI is Hard

I can't stress this point enough. There's so much more to GUI than meets the eye.

Edit:

Now while that point still stands, I think I was being unfair with my previous edit.

There's a lot of "one man" Rust GUI libraries out there. There's nothing wrong with that, and they can already be used for a wide variety of applications. I think most if not all these projects aren't actually trying to directly compete with the likes of QT, JUCE, GTK, Flutter, Electron, etc. They are aiming to be a solution for a different problem, and I believe they are achieving that very well.

My personal favorite is egui, it makes it so easy to whip up prototypes, and the performance isn't bad either.

With that out of the way, I still want to give you my list from the previous edit. The point I'm now making is that if the goal of a particular Rust GUI library is to compete in the big leagues, there are a lot of complicated hidden details that must be addressed. While not every one of these features need to be included, I think it gives a good overall idea of the complexity we're dealing with here.

Some of these features include:

JUCE doesn't actually have a lot of these features. Its focus is on audio software, and not general use. Existing Rust libraries like vizia, iced, and egui are already quite competent at the audio plugin use case (which is the majority of JUCE's user base).

The rui library also seems promising for this use case since it is specifically being used for a commercial audio application. Though I'm not sure anyone has actually tried to make an audio plugin with it yet.

What I Learned About Open Source

I learned a very important lesson from my struggles. Not just my struggles with the UI, but with Meadowlark itself.

You can't rely on volunteers to build key components of a large open source project. Unless you have found someone else who is as passionate as you are, has the same vision as you do, and has as much free time as you do (or unless you're running a business with employees), you must be prepared that you will be working on it alone for a long time. You must be prepared that you will do the vast majority of the work yourself. You also need to understand your limits as a solo developer (which is something I previously grossly miscalculated).

What I'm Doing Now

I learned that I simply cannot make both a DAW engine and a DAW frontend on my own. I severely underestimated the frontend. I'm only one person.

But that's ok, because I actually have found someone else who is working on their own DAW frontend, and they are very good at it. By coincidence (or maybe it's fate?), they share a similar vision to what I had with Meadowlark's UI. So we decided to team up, with them working on the frontend and me working on the backend engine.

They're using Flutter, and it's impressive what they were able to do with it. So Meadowlark (or whatever we end up calling it) will use Flutter for mainly that reason.

They were originally going to use the Tracktion Engine for the backend, but they agreed that having a new open source engine would be beneficial.

And so here's what I'm doing now: I'm creating my own DAW engine like Tracktion's, but with these notable advantages:

Maybe I might even try monetizing the engine in some way. Whether that be dual-licensing or sponsorships, I haven't decided yet.

This DAW engine will be called Dropseed (following the naming scheme I have of native fauna and flora in Kansas. Dropseed is the name of a grass).

I'm also creating an FL Studio Patcher-like plugin as a testbed for my engine. I eventually want to have a Patcher-like plugin in Meadowlark anyway, so it's still a good use of my time.

BTW, I'm not going to mention who this person is or what project they were working on yet. I don't want to drive unwanted attention towards them.