Our great sponsors
- Revelo Payroll - Free Global Payroll designed for tech teams
- Onboard AI - Learn any GitHub repo in 59 seconds
- SonarCloud - Analyze your C and C++ projects with just one click.
- InfluxDB - Collect and Analyze Billions of Data Points in Real Time
-
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.)
-
Revelo Payroll
Free Global Payroll designed for tech teams. Building a great tech team takes more than a paycheck. Zero payroll costs, get AI-driven insights to retain best talent, and delight them with amazing local benefits. 100% free and compliant.
-
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:
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.
-
ToobAmp
A set of high-quality guitar effect plugins for Raspberry Pi with specific support for PiPedal.
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.
-
Onboard AI
Learn any GitHub repo in 59 seconds. Onboard AI learns any GitHub repo in minutes and lets you chat with it to locate functionality, understand different parts, and generate new code. Use it for free at www.getonboard.dev.
-
slint
Slint is a declarative GUI toolkit to build native user interfaces for applications that are written in Rust, C++, or JavaScript.
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.
-
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:
-
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:
