As for graphics performance, I think the heavy lifting is done by Qt6, as it took advantages of modern GPU rendering APIs on each platforms (e.g. Metal on macOS and DirectX 11 on Windows).
What we did to keep the UI responsive is more of following the best practices when possible, things like:
* Use QML binding when we can (e.g. serving data from C++/Rust via Qt View Models), this so that frequent data changes will be batched to UI redraws only when needed
* Use C++/Rust as much as possible for calculating data needed in the UI rendering (e.g. the waveform's data)
* Avoid fractional pixel position/sizes during animation (e.g. by rounding the values), so that UI redraws are quantized to changes on visible pixels
We decided to use Qt because we previously worked in a few successful commercial audio projects with it (for our previous employers), and felt quite positive with those - so mostly just to work with what we already know, as the audio side of the project also requires a fair amount of attention, and we are a very small team.
We have an upcoming article about the technical details of the project [1], perhaps that will be interesting to you, if so stay tuned :)
Plugin host in Teapodo is done in two main modules:
- The Teapodo audio engine provided "plugin slots" for the application to mount plugin instances to (in a thread safe way), which is written in Rust
- The plugin format parsers to understand each plugin formats (e.g. VST3, AU) and create plugin instances from, which is written in C++ and is just a thin wrapper around JUCE
We did think about building our own plugin format parsers from scratch, but since we are really small (only 2 devs) we ended up using an existing solution for now. Maybe we will come around and do it at some point (I certainly hope we could!).
As for releasing the source code, that's definitely a possible option. We've seen some interest in the implementation of the project, and we will start by writing about it soon, so stay tuned!
Yes, we will eventually try to make it a sustainable business.
We don't have a concrete licensing plan yet, but we are hoping to keep all released functionalities free to use so that existing users won't be interrupted.
It's not open source yet, but it's certainly a possible option.
Hi, Yan from Teapodo here. Thanks for the feedback!
- Glad it felt smooth and fast to you, that's exactly what we are striving for.
- For the plugin list issue, yes, we also noticed that before release, we are planning to add plugin search/filter in the next iteration.
- On wave editing (and potentially spectrum analysis), we had some ideas around this, but we aren't able to fully commit to these yet (we are a very small team). I see your point and I think we will think more carefully about how we present the main selling point of Teapodo in the future (same goes for the "lightweight" part).
- Vertical zoom and grouping clips: these also came up when using it internally, so we will also look into these soon.
This is indeed a very interesting idea - taking advantage of the existing ecosystem. Like what the Language Server Protocol has done to the text editing world.
Thanks for the suggestion and we will definitely consider it.
Yes, we structured our application around C++, and the Rust part is more of an internal library called from C++ via FFI.
We took this approach initially because I had done this before in another application[1], and I was quite happy about the result then.
Also, as we are a very small team (2 developers) developing a cross-platform application, we thought it makes sense to only use Rust to solve the hardest part first (i.e. the audio engine) and offload other complexities (e.g. a cross-platform GUI, reactive data binding, etc.) to some existing frameworks (Qt in this case), so that we are less likely to be overwhelmed.
We did end up with writing the whole application's data flow in Rust as well (e.g. the whole application state tree, the undo/redo, and all of the business rules such as audio clip size constraints, etc.). We did it because we thought it's also a pretty isolated problem, so the whole thing can be easily encapsulated in pure Rust without interacting to much with other systems.
Our experience of doing it this way was pretty good. We basically live in two worlds: the core Rust library and the GUI (in fact they are even separate Git repositories). We follow best practices in each worlds, and they interact with each other using FFI (in C).
The only negative side of this for us so far is that there are some manual steps involved when crossing the FFI boundary (on either directions), for example:
- When providing a functionality from the Rust library to the UI, we need to write an unsafe C ABI binding for each API we want to expose
- On the other direction, if we want to pass complex data structures from the UI to the Rust library, we would need to either interpret the data using C primitives or create an opaque type and require the UI to properly initialize the data
I believe there might be ways to make it more ergonomic (e.g. procedural macros, or some existing crates such as cxx), and we will certainly look into improving it at some point!
---
[1]: I built a Unicode tool for macOS and iOS, with the UI being written in AppKit and UIKit, and the Unicode data being provided by Rust.
As for graphics performance, I think the heavy lifting is done by Qt6, as it took advantages of modern GPU rendering APIs on each platforms (e.g. Metal on macOS and DirectX 11 on Windows).
What we did to keep the UI responsive is more of following the best practices when possible, things like: * Use QML binding when we can (e.g. serving data from C++/Rust via Qt View Models), this so that frequent data changes will be batched to UI redraws only when needed * Use C++/Rust as much as possible for calculating data needed in the UI rendering (e.g. the waveform's data) * Avoid fractional pixel position/sizes during animation (e.g. by rounding the values), so that UI redraws are quantized to changes on visible pixels
We decided to use Qt because we previously worked in a few successful commercial audio projects with it (for our previous employers), and felt quite positive with those - so mostly just to work with what we already know, as the audio side of the project also requires a fair amount of attention, and we are a very small team.
We have an upcoming article about the technical details of the project [1], perhaps that will be interesting to you, if so stay tuned :)
[1]: and here is a sneak peek https://twitter.com/teapodo_audio/status/1559695230693101568...