Какой GUI фреймворк выбрать для pro audio?

Есть задача создать графическую консоль управления для профессиональной системы аудио микширования и сведения. Про-Аудио дело тонкое и очень требовательно в плане UI/UX. В приложении, кроме простых ручек, фейдеров и кнопок должны быть спектрограммы, формы волн, различные измерители, изменяющиеся в реальном времени каждые 30-60 кадров в секунду. В общем, все серьёзно и почти как в современных DAW. Лицензирование - скорее всего, проприетарщина.

Сейчас я участвую в прототипировании такой консоли на ElectronJS. Это позволяет быстро реализовать идеи по графике, расположению элементов и в итоге найти идеальный вариант. Но мне видится, что для боевого решения ElectronJS не подходит, ибо выходит все шибко жирно - как по памяти и производительности, так и по размеру дистрибутива.

Следующие, что приходит на ум, это всемогущий Qt. Но и здесь у меня возникают сомнения. Qt не просто GUI фреймворк. Приложение по своей сути довольно "низкоуровневое". Оно не будет иметь дело ни с обработкой аудио, ни с автоматизацией. Только общение по протоколу OSC (UDP/TCP/WS), отрисовка текущего состояния и отправка действий пользователя. Стоит ли ради этого тащить целый Qt?

Мне нравится как сделано приложение для управления цифровым микшером Behringer X32 - X32 Edit. Все приложение - один маленький исполняющий файл. Причем есть дистрибутив сразу для windows, mac и linux. Потребление ресурсов просто фантастическое и оно работает идеально. К сожалению, мне не известно, на чем оно сделано.
  • Вопрос задан
  • 184 просмотра
Решения вопроса 1
Qt + Qml
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@Showvars Автор вопроса
Immediate mode UI оказалась действительно удобным решением для моего случая. Попробовал на зуб одну уникальную библиотеку Nuklear на OpenGL бекенде. Из плюсов - хорошая производительность и отзывчивость. Несмотря на то, что пробное приложение написано на Си, это позволило использовать часть кодовой базы от основного "серверного" проекта (сеть, OSC таблица и прочее) без ущерба читабельности кода. В связке с асинхронным I/O получается прикольная конструкция: в одном event loop мы получаем изменения состояния извне, обрабатываем действия локального пользователя, отправляем при необходимости изменения на сервер и рисуем итоговое состояние на экран. Такое даже получится на встраиваемых системах запустить.

Но использование Nuklear не обошлось без недостатков. Я сразу же столкнулся с неприятными особенностями:
- Оказалось достаточно сложно кастомизировать существующие виджеты. Если со стилями еще можно побороться, то вот менять поведение элементов уже не так просто.
- Проблематично создавать свои виджеты. Да, там есть простое API для рисования, с помощью которого можно сделать что угодно, но тогда большая часть библиотеки окажется не нужна (базовые элементы там реализованы довольно лаконично, не хочется дублировать это для локального случая).
- Layouting. Все API для верстки завязано на строках с колонками с привязкой по ширине (по высоте пока нельзя). Местами приходилось все делать либо с абсолютным позиционированием, либо поправлять падингами, либо расставлять костыли и использовать грязные хаки.

В итоге использовать напрямую подобные библиотеки пока что не представляется возможным. Все таки интерфейс должен быть очень не стандартным. Возможно в дальнейшем получится потратить время и сделать свой более общий Nuklear для создания произвольных интерфейсов. Все таки в Nuklear есть отличная идея с буфером команд , списками вершин и элементов. Как ядро это можно вполне успешно использовать. Пока что это только мысли.

Вопрос конечно получился очень специфический и наверно его стоит закрыть.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы