I’m sorry, but I think I have to get some of you down to earth a bit:
First of all, don’t reinvent the wheel: Have you had the pleasure to work with something professional like Ableton Live yet? This piece of software is in continuous development for over 19 years now and was created by people who know their craft pretty well. And compared to the competition, Ableton Live is rather young: Logic Pro is 27 years old, and Pro Tools and Steinberg Cubase are even 31 years old! All of these DAWs are under constant development and are extremely specialized and optimized, both regarding pure rendering performance and ergonomics. They already excel at everything you might want a DAW to do and the bar for new DAWs is damn high. Reinventing the wheel isn’t going to get you anywhere, you’ll just do what all the other people did in the 2000s. Try to do something new that hasn’t been done (properly) before!
Another thing is that “It’s written in Rust” is not a feature for the user of an application. I love to create libraries and frameworks in Rust, but when the user is only using an application, the language it was written in shouldn’t be important. If a user asks you why they should use your software and your only answer is “It’s written in Rust” you’ve done something wrong. Try to offer something new that hasn’t been done (properly) before, even if it involves not using Rust! However, “It’s Open Source” is a feature because it means that the users are independent of the original authors, but that’s a story for another time.
The last thing is that you seem to underestimate the power of platforms. Why do you think everyone uses VST? Not necessarily because it’s the best technology out there, but because almost all hosts and plugins support it. Building up a new platform without a way to transition to it usually doesn’t work since no one wants to use a platform with nothing on it. Try to work together with other technology to become relevant. Rust-VST and Rust-LV2 wouldn’t have caught on if no host would support them.
Okay, rant over, sorry for that! Maybe I should say now what I want to do. You’ve probably figured by now that I consider the DAW business as more or less sorted out. However, one thing that isn’t sorted out to me is a proper translation of conceptually modular synthesizers to software solutions. There are quite a lot of approaches and things I’ve tried out, for example VCV rack, Carla and Reaktor, but they all fail for the same reason: They limit their possibilities by clinging to outdated metaphors.
Take, for example, VCV Rack: Its goal is to exactly replicate modular Eurorack synthesizers. These are basically suitcases filled with modules that can be connected with audio cables and control each other by applying voltages to these cables. This concept is pretty neat, but clinging to firmly to it leads to unnecessary restrictions: For example, modules in VCV Rack can not be folded together, hidden, or abstracted into new modules, because you can’t do that with hardware modules. The connections can also only carry single-voiced audio data, no events, or other formatted data. Another odd detail that really annoys me is that VCV Rack doesn’t integrate with any other software/DAW since it considers itself as a DAW too (Source: https://vcvrack.com/manual/FAQ), which it straight-up isn’t. However, it is extensible via its own plugin standard, which is better than nothing.
Reaktor does a better job: It’s a visual programming environment where you arrange modules in a graph to describe a higher-level synthesizer. Modules can be grouped and abstracted into macros, and you can also build some neat UIs to use your completed synth in another application. It also has so-called “core modules” which use a Petri net instead of a graph and are compiled on-the-fly for some extra performance. Native Instruments use it to build almost all of their synths and I’ve also put it to some good use and created some nice sounds with it, but it’s hard to describe any concepts that aren’t exactly DSP programs. For example, it can only work directly with simple data types like floats or ints, and you can not directly interact with the operating system, create new UI elements, or run tasks in the background. Lastly, it’s a closed system, which means that you cannot extend it with “proper” libraries to work around the issues I’ve described above. All in all, I’m okay to work with Reaktor for now, but it’s far from perfect.
Another piece of software that always stands out to me is Carla. It describes itself as a “fully-featured modular audio plugin host” (Source: https://kx.studio/Applications:Carla), which fits quite nicely: It supports many plugin standards and lets you arrange instances of these plugin in a graph, a bit like Reaktor. It’s also available as an LV2 or VST plugin and therefore integrates into other applications. However, its editing and arranging capabilities aren’t as powerful as those of Reaktor and it doesn’t support the unique features of LV2, like Atom ports for the exchange of arbitrary data between plugins. I guess that the goal behind Carla is to provide a virtual studio with a few dozens of big sound processors, not hundreds of small synth modules. It also focuses too much on supporting everything, at least for my taste: It can host plugins of almost all relevant standards and operates with a lot of audio drivers. This requires a lot of constant maintenance and development power that isn’t spent on actual features. Also, telling from which features are considered “experimental”, its architecture isn’t really made for the things that Reaktor can do.
Concluding, I basically want an open-source version of Reaktor that hosts LV2 plugins instead of having built-in cells. This would mean that I could just jam together synthesizers to create the sounds I want and use them in my Ableton projects, but if I want something that can not be expressed as a graph or want to have more performance, I could implement it as a native LV2 plugin node. I’m explicitly mentioning LV2 here because it’s an established standard that can be easily extended and that I know it quite well by now. It would be stupid for me not to use it.
Notice how I didn’t mention Rust until this point. To be honest, I don’t necessarily need this software to be written in Rust. I just want this software to make music, and if someone else happens to write it in C++ or even C, I’m fine with that. The language an application is written in isn’t a feature and it might also be better to not use Rust for the frontend / UI because other, more mature technologies have better tools available. I’m maybe thinking about QtQuick backed by a static C++ or Rust library, but I haven’t made my mind up on that.
That’s my vision. Sadly, my time and energy for it have diminished quite a lot in the last months. I almost quit Rust-LV2 entirely, but since activity here and on Github has sparked up again lately, I might come back again. My next step would be to write a product vision that precisely describes what I want to do and can be used as a reference for further discussion and development. What do you think?