Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Digital Audio Workstation Front End Development Struggles

billydm.github.io

Post reply on HN
Print view View original

141–150 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#141

Post by lolrustards »

andrewmcwatters wrote: post #36
grumpyprole wrote: post #29

> This performance is not a problem if the app is small or the app already redraws every frame like a video game. Seems to me like immediate mode UIs were dismissed rather too quickly. Why not update a DAW UI like a video game? It has similar realtime requirements.

Immediate mode GUIs have significant limitations. You can probably lie to your end users by saying the API is immediate mode styled, but actually retained under the hood (and I think to some degree, this already happens today with cached state), but I think that defeats the point.

It's a trade off.

With ImGui you can definitely have a GUI that is:

  1. Very complex
  2. Able to use custom, complex widgets
  3. High performance
  4. Written very quickly with a very simple API
Those are significant pros.

There are a few serious downsides as well:

  1. It is not remotely conforming to the platform's standard UI (a bit less a problem for a DAW since they all have custom GUIs and widgets anyway)
  2. The font rendering is done by the GPU using cached textures, so it's more limited in terms of what you can achieve there (not so much a problem for DAWs because you don't have much text to display)
  3. Power usage can be high unless you use tricks to adjust the frame rate dynamically
  4. It's in C++, which can be a con for some people (although it's written in old-school C-like style)
If you can live with those, it's a great solution.

People do crazy stuff with Dear ImGui: 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.)

Re: Digital Audio Workstation Front End Development Struggles

#142

Post by conradfr »

andybak wrote: post #70

> Ideally I want to support loading user-generated themes. I really hope this just means "alternative colour palettes". Otherwise they're about to make one of the hardest UI programming tasks I can imagine exponentially harder. I've never understood the passion for themeability. It's like going into a restaurant and expecting to participate in the cooking of your meal. As much nostalgia as I have for the heyday of Wi…

On the other hand the Reaper DAW has colour and theme layouts and also has a very performant UI just like Winamp.

I guess you just need to be as good as Justin Frankel ;)

Re: Digital Audio Workstation Front End Development Struggles

#143

Post by bandika »

It’s a hard problem, and I don’t think there is a single solution for a DAW UI. On the one hand there are a lot of UI elements that can be built with traditional widget kits, like the toolbars, panels, even knobs and sliders just custom widgets, you can even build a channel strip that way.

On the other hand there are the “contents” or “views” like track view, clips, automation, piano roll, eq etc. I believe those are best to be handled as 2D scene graphs with direct GPU rendering. Even then, each of those DAW specific views presents their own set of challenges which are very involved to address.

So I would definitely choose a toolkit that allows both traditional widget trees as well as scene graph style rendering (for eg Egui + wgpu in rust, or Qml in C++).

There are other challenges too, I’ve always found synchronizing the ui, the rendering and the audio thread so that everything feels responsive is very hard.

Re: Digital Audio Workstation Front End Development Struggles

#144

Post by rickdeckard »

porkbeer wrote: post #2

Its weird to see the impressions of someone who has apparently never used the equipment used in music production trying to talk intelligently about said devices. So many incorrect assumptions its really painful to read as someone aquainted with audio engineering. Interesting window into how the devs see it nonetheless.

I find the article actually refreshingly dry. The author acknowledges and breaks down a large series of interface requirements for a music production tool and approaches it from a pure development point of view.

I wonder what are the "many incorrect assumptions" you see. I didn't notice any attempt to judge or discredit any of the requirements, he merely described them in a very sober way.

For someone very familiar with audio equipment it was a nice read for me. It's like reading a summary of user expectations to switches and knobs in a car, from a pure GUI development point of view.

Re: Digital Audio Workstation Front End Development Struggles

#145

Post by akdor1154 »

jupp0r wrote: post #87
usernew wrote: post #38

Earlier quoted context omitted.

Alright, here's I want you to do. It'll be interesting and fun, you'll make something cool, it's free, and then you'll come back and look at your comment and reply with a "/s." Download pirated copies of protools and melodyne, and a bunch of virtual instrument libraries from torrents. Download a midi file for a song you like, dump it into protools. Record yourself singing, right on the PC or headset mic - no need to…

Until last year, I worked on a team that built an electron app for video conferencing with a double digit million user base. We did audio processing (mixing, RNN noise reduction) via WebAudio in WASM. This is in production right now as far as I know and adds very little latency. That being said, this is about GUI. No reason not to do as much native processing as your heart desires outside of your GUI layer.

> This is in production right now as far as I know and adds very little latency.

How much? As GP said, > 5ms is instant disqualification. And that is for your whole app, not just the effects pipeline.

GP is right, go use a DAW in a serious setting for a while to build up an intuition of the needs of these users.

Re: Digital Audio Workstation Front End Development Struggles

#146

Post by alpaca128 »

sirsinsalot wrote: post #102
thorncorona wrote: post #69

Earlier quoted context omitted.

Discord and Slack are both nicely optimized web apps but they're not very fast compared to native apps. You can tell that there's a noticeable lag between when you type into discord versus the terminal.

I didn't realise the bar latency had to get over was a comparison to a terminal! I best throw every ide or tool I've ever used in the bin!

FYI, most terminals are more on the slower side. For example intelliJ has a much lower input latency than most terminals. So it's not really an unreasonable expectation, many apps are just really damn slow.

Re: Digital Audio Workstation Front End Development Struggles

#147

Post by gattis »

Not the coolest answer but I feel like QT is gonna be hard to beat here. It has a ton of this functionality already, signals are not the enemy for something this complicated and time-driven, it runs on anything and performance is great, and its pretty powerful/flexible when you need to whip up custom graphics stuff. QML and JS are really nice to have. I wrote a modular synthesizer GUI with it (https://github.com/ohmbre/ohmstudio.git). Took a gamble on QT5 because I wasn't a big fan of QT4 or below, and don't much like KDE, but it turned out perfect. Just never came across anything and said "ew well that's gonna be hard with the tools I have." There was always something handy. GUI never got in the way of audio performance, as long as its on its own thread and using ring buffers etc, you're fine.

Re: Digital Audio Workstation Front End Development Struggles

#148

Post by phkahler »

gattis wrote: post #147

Not the coolest answer but I feel like QT is gonna be hard to beat here. It has a ton of this functionality already, signals are not the enemy for something this complicated and time-driven, it runs on anything and performance is great, and its pretty powerful/flexible when you need to whip up custom graphics stuff. QML and JS are really nice to have. I wrote a modular synthesizer GUI with it ( https://github.com/ohm…

I'm not QT or any other gui toolkit is well suited for this. Every widget is custom and many require high framerate / low latency.

It's probably best to treat it like a video game and just render everything every frame. Only use gui events to affect the underlying data model, don't trigger any gui updates or rendering from them. In this light you're looking for fast software or OpenGL rendering as the key feature in the toolkit, but you still want menus and toolbars.

Re: Digital Audio Workstation Front End Development Struggles

#149

Post by kuschku »

andrewmcwatters wrote: post #19
bsder wrote: post #15

Earlier quoted context omitted.

> Pixel fill is expensive. And how. People don't realize that even with modern graphics card bandwidths, windows that are a good fraction of a 4K monitor take a remarkable amount of bandwidth to clear and fill.

Thank you! Man, if you could get people who work on UIs to write a shader once in their software career and tell them, hey how do you get a nice Gaussian blur to draw fast on a 4/5/8k monitor, they'll quickly realize you need to do as little drawing as possible.

Gaussian blur is "easy", you can decompose it into a vertical and horizontal component and parallelize and vectorize most of the task.

But that's a special case. If you have to actually fill the buffer the traditional way, it takes an eternity.

Which is why I'm so disappointed by Gtk's decision to say "just draw at 6K at 2x if you want 4K at 1.5x, scaling is cheap". Because it's definitely not.

Re: Digital Audio Workstation Front End Development Struggles

#150

Post by spacechild1 »

bambax wrote: post #72

I don't know much (or anything, really) about DAW development, but as a Reaper user I know you can make a cross-platform DAW that performs extremely well on very little ressources, including displaying many instances of all the things the author is talking about (spectrograms, audio files, zoomable midi clips, etc.) in real time, on a Raspberry Pi, while playing audio and driving physical synthesis plugins.

True! Fun fact: Reaper uses its own UI framework. Parts of it are open source: https://www.cockos.com/wdl/
Post reply on HN