Which GUI framework to choose for pro audio?

Question

User interface

There is a task to create a graphical control console for a professional audio mixing and mixing system. Pro-Audio is a delicate matter and very demanding in terms of UI/UX. In the application, in addition to simple knobs, faders and buttons, there should be spectrograms, waveforms, various meters that change in real time every 30-60 frames per second. In general, everything is serious and almost like in modern DAWs. Licensing is most likely proprietary.

Now I am involved in prototyping such a console on ElectronJS. This allows you to quickly implement ideas on graphics, the location of elements and, as a result, find the perfect option. But it seems to me that ElectronJS is not suitable for a combat solution, because everything comes out very bold - both in terms of memory and performance, and in terms of the size of the distribution.

The next thing that comes to mind is the almighty Qt. But even here I have my doubts. Qt is not just a GUI framework. The application is inherently quite "low-level". It won't deal with audio processing or automation. Only communication via the OSC protocol (UDP / TCP / WS), drawing the current state and sending user actions. Is it worth dragging the whole Qt for this? I like how the Behringer X32 - X32 Edit

digital mixer control application is made . The whole application is one small executable file. And there is a distribution immediately for windows, mac and linux. The resource consumption is fantastic and it works perfectly. Unfortunately, I don't know how it was made.

Answer 1

Qt+Qml

Answer 2

Immediate mode UI turned out to be a really convenient solution for my case. I tried one unique Nuklear library on the OpenGL backend. Of the benefits - good performance and responsiveness. Despite the fact that the trial application was written in C, this allowed us to use part of the code base from the main "server" project (network, OSC table, etc.) without compromising the readability of the code. In conjunction with asynchronous I / O, a cool construction is obtained: in one event loop, we receive state changes from the outside, process the actions of the local user, send changes to the server if necessary, and draw the final state on the screen. This will even work on embedded systems to run.
But using Nuklearnot without drawbacks. I immediately encountered unpleasant features:
- It turned out to be quite difficult to customize existing widgets. If you can still fight with styles, then changing the behavior of elements is no longer so easy.
- It is problematic to create your own widgets. Yes, there is a simple drawing API with which you can do anything, but then most of the library will not be needed (the basic elements are implemented there quite concisely, you don’t want to duplicate this for a local case).
- layout. The entire API for layout is tied to rows with columns bound by width (height is not yet possible). In some places, I had to do everything either with absolute positioning, or correct it with padding, or set up crutches and use dirty hacks.
As a result, it is not yet possible to use such libraries directly. All the same, the interface should be very non-standard. Perhaps in the future it will be possible to spend time and make your own more general Nuklear to create arbitrary interfaces. All the same, Nuklear has a great idea with a command buffer, lists of vertices and elements. As a core, this can be used quite successfully. So far, these are just thoughts.
The question, of course, turned out to be very specific and probably should be closed.