Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
ToobAmp
A set of high-quality guitar effect plugins for Raspberry Pi with specific support for PiPedal.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
slint
Slint is a declarative GUI toolkit to build native user interfaces for Rust, C++, or JavaScript apps.
-
-
In ossia.io I use three different algorithms / display methods depending on the zoom level used: at "far away" zoom it uses the minmax of the audio slices, at intermediary zoom it draws lines and when getting closer, it starts drawing individual samples.
https://github.com/ossia/score/blob/master/src/plugins/score...
- Automation clips can contain a bunch of bezier curves, which are slow to render.
Convert those to line segments with an approximation setting that looks good enough and it'll be ten times faster (keep the bezier for your data model of course).
https://github.com/ossia/score/blob/master/src/plugins/score...
https://github.com/ossia/score/blob/master/src/plugins/score...
- Piano roll clips can contain lots of little rectangles in order to display a "minimap" of the MIDI notes inside of it.
oh damn yes, I spent so much time on this and it still needs so much optimizing... if someone wants to give a shot at it :D
https://github.com/ossia/score/blob/master/src/plugins/score...
https://github.com/ossia/score/blob/master/src/plugins/score...
- On top of all this, clips can contain text labels which can also be expensive to render.
Yep, made myself a few "cached text" Qt items over time as the builtin cache wasn't satisfactory
- The fact that a timeline is zoom-able also makes it harder to cache the rendering of clips. If the timeline changed its zoom level, all visible clips pretty much have to redraw all of their contents.
yep
- Piano rolls can also be expensive to render if there is a bunch of MIDI notes, especially if there are text labels on the notes.
yep
- If the user clicks on a folder in a sample browser containing hundreds or even thousands of files, allocating a label widget for each file in the browser list will be very expensive. Something like the list factory in GTK is needed here.
yep, Qt's also able to cache this. Though for instance for Qt's QFileSystemModel I carry a small patch to disable any kind of sorting when there's more than a few hundred thousand files (which happens for large media libraries)
- We want to reserve as much CPU as possible for the actual audio processing. Ideally the GUI shouldn't take up more than one or two CPU threads.
https://github.com/ocornut/imgui/issues/5886
(And keep in mind that many of those are week-end / hobby projects, by people who prefer to focus on other things than the GUI of their projects.)
And its "design document": https://github.com/MeadowlarkDAW/Meadowlark/blob/main/DESIGN...
for small effects, I think EGUI is usable already. Here is a Dattorro reverb VST plugin written in Rust with egui and glicol_synth:
https://youtu.be/DLFO4dXzKsg
Since EGUI can be used almost every where, I also made an experimental front end for Glicol with EGUI: https://glicol-egui.netlify.app/
But there are many features missing, compared with HTML/CSS: https://glicol.org/
The biggest issue with EGUI is that the style seems to be quite fixed. The default style looks great for some customisation would be more ideal in some context.
although we are not there yet, it's great to see more and more attempts for audio /gui in rust. And I really feel that Rust is the best choice for the audio backend now.
Doubly horrifying. Not only is it poisonously ugly; it's also fixed ugly. Srsly dude. That is not something that makes you want to use egui.
(My plugins: https://github.com/rerdavies/ToobAmp using a web interface; I'm currently weighing options for GUI backend for a Linux native interface. LV2 plugins infamously cannot use GTK or QT).
> But no one is saying, "Hey I have a CSS 2.1 compliant rasterizer and compositor that you can use in your C++ or Rust environment!" are they?
There’s actually quite a lot of interesting work going on in that general space, has been in various forms for some years. A couple that immediately spring to mind:
• Azul <https://azul.rs/> builds on WebRender, as used in Firefox. I haven’t looked at it for a few years, but it looks to have grown quite interesting now.
• Blitz <https://github.com/DioxusLabs/blitz> is based on from-scratch implementations of CSS layout and rendering, and wgpu rendering. It’s not usable yet, but is a very interesting concept. If one happens to be familiar with React Native: it’s kinda like that, or React Native Web.
> But no one is saying, "Hey I have a CSS 2.1 compliant rasterizer and compositor that you can use in your C++ or Rust environment!" are they?
There’s actually quite a lot of interesting work going on in that general space, has been in various forms for some years. A couple that immediately spring to mind:
• Azul <https://azul.rs/> builds on WebRender, as used in Firefox. I haven’t looked at it for a few years, but it looks to have grown quite interesting now.
• Blitz <https://github.com/DioxusLabs/blitz> is based on from-scratch implementations of CSS layout and rendering, and wgpu rendering. It’s not usable yet, but is a very interesting concept. If one happens to be familiar with React Native: it’s kinda like that, or React Native Web.
It seems you may have used the FemtoVG backend, which is the default if Qt is not installed and is written in pure Rust. We offer multiple rendering backends, and you may have better results with the Qt or Skia backend, which utilize native font rendering. Additionally, a recent change made improvements to address this issue in our FemtoVG backend: https://github.com/slint-ui/slint/pull/2618
There's a relatively new C++ GUI library literally called "Elements". Not sure how it works though, but the way it looks, and the music background of its creator makes it appear designed for DAWs.
https://github.com/cycfi/elements
I spent some time last year building out a UI framework for VSTs based on embedded HTML, after being frustrated with the terrible VST GUI package from Steinberg. I think it showed promise, but I'm unable to continue to make progress with it:
https://github.com/rdaum/vstwebview
It'd be great if somebody were to run with it. I feel I made good initial progress. These days, I have to concentrate on my paying work (in Rust, not C++) instead.
I agree web stuff is really the best way to develop UIs. Good luck making responsive stuff in C++ for example. The paradigm of HTML, CSS, and JS is extremely powerful and even allows you to use canvas, webgpu, wasm.
There are multiple commercial projects that use web dev paradigm for GUIs:
https://coherent-labs.com/
https://ultralig.ht/
https://sciter.com/
I agree web stuff is really the best way to develop UIs. Good luck making responsive stuff in C++ for example. The paradigm of HTML, CSS, and JS is extremely powerful and even allows you to use canvas, webgpu, wasm.
There are multiple commercial projects that use web dev paradigm for GUIs:
https://coherent-labs.com/
https://ultralig.ht/
https://sciter.com/