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

261–270 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#261

Post by lelanthran »

ogoffart wrote: post #259
lelanthran wrote: post #228

Earlier quoted context omitted.

> We are also actively working on a visual editor that lets users drag and drop widgets. Such capabilities are difficult or impossible to achieve with imperative APIs I don't think you have ever used an imperative API, have you? I used VB, then Delphi, then C++ builder and now use Lazarus, and there's no declarative equivalent that is easier or faster than those.

In the examples you mentioned, the UI is typically described in XML or form files (.dfm), which is essentially a declarative approach, and clearly not described in imperative code. Although they may not be intended to be edited by hand, the underlying representation is still declarative in nature.

Agreed, but they were easily achieved with imperative APIs.

This is the statement I was contending:

> We are also actively working on a visual editor that lets users drag and drop widgets. Such capabilities are difficult or impossible to achieve with imperative APIs

Maybe I should have said "there's no declarative-only equivalents that's easier or faster".

As someone else pointed out elsethread, declarative is a subset of imperative, so it's easy to produce an imperative API that consumes machine-generated declarations, but not so easy to use a declarative-only framework to reproduce the ease and speed of Delphi, Lazarus, etc.

Re: Digital Audio Workstation Front End Development Struggles

#262

Post by zigzag312 »

jupp0r wrote: post #247
TheOtherHobbes wrote: post #129

Earlier quoted context omitted.

A DAW is going to be doing far more audio processing on tens or hundreds of channels simultaneously, while playing back some of the audio from disk, some from memory, some from live inputs, and also receiving, processing, and recording/playing MIDI events. And hosting both the audio and GUIs of third party plugins.

That makes sense, but what does that have to do with how GUI is implemented?

DAW's GUI needs to remain responsive with minimal and consistent latency. If DAW users complained because of DPC latency introduced by Nvidia's video driver, you can imagine how critical low-latency requirements are.

DAW can use pretty much all of system resources (RAM, CPU, disk IO) during playback. If any other thread steals CPU for for too long during playback, like GC of an UI thread, this can introduce audio clicks/pops.

Video conferencing app has tons of network latency which helps to hide other latencies. That kind of latency would be unacceptable in a DAW. Video conferencing app also doesn't starve system of resources like DAW can, so it's UI can be more resource-intensive.

Re: Digital Audio Workstation Front End Development Struggles

#263

Post by richrichardsson »

outsomnia wrote: post #111
richrichardsson wrote: post #68

Earlier quoted context omitted.

I can assure you that users complain when the GUIs of DAWs start to run below 30fps, and really the expectation these days is that "performant" GUIs run at 60fps.

I am suggesting confirming if it is actually "slow" for the "key aspects". You and the OP are just assuming it can't do whatever it is at "30fps"... if you're right, it will only take ten minutes if it's so bad, or an hour or two if it's subtle, to actually confirm whatever the worst thing is. The "extra frame" I was thinking of is graphics pipeline latency, not redraw time.

Well now you're assuming what I'm assuming, which is fair enough because I assumed by your comment that you were saying the UI responsiveness isn't really a concern in DAWs. It's definitely a secondary concern, but people are accustomed to buttery smooth UIs and complain when they're not.

That said, I'd argue that even latency is still a concern for things like meters. If they are noticeably out of sync with what you hear then users will again complain.

Re: Digital Audio Workstation Front End Development Struggles

#264

Post by pkphilip »

andrewmcwatters wrote: post #16
chaosprint wrote: post #13

DAW is so challeging! But in terms of audio effect plugins, 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 music language with EGUI: https://glicol-egui.netlify.app/ There are many features missing, compared with HTML/CSS: https://gl…

I don't think you can meaningfully use immediate-mode GUIs for anything related to compositing work. If you're creating debug UIs or basic UIs at best, you're fine. That might actually work out alright for DAWs, but if you want sophisticated user-interfaces where you can add effects to things, you need to start retaining graphics data, and so many people advocating for these old school immediate-mode GUI libraries ju…

Immediate mode gui - psuedocode where volumeSlider is a slider used for setting the audio volume and spectrograph includes a bar which displays the volume visually:

function volumeSlider_onChange() { audioEngine.setVolume(volumeSlider.value); spectrograph.setVolume(volumeSlider.value); }

function stopButton_onClick() { audioEngine.getCurrentTrack().stop(); }

function audioEngine_statusCallback(Track track) { spectrograph.update(track.status); }

To do something like this in a declarative UI, you will need some sort of a state machine, that state machine will then need to have a bunch of state variables, callbacks/hooks, providers/notifiers etc. And you have to have this managed for each variable.

That is, there will be a LOT more code that needs to be run before updates flow from the GUI to the engine or from the engine back to the GUI.

Why would you think that declarative UI will be more efficient?

Re: Digital Audio Workstation Front End Development Struggles

#265

Post by pkphilip »

BillyDM wrote: post #234

The writer of the blogpost here. The popularity of this post has really caught me at an awkward time. I want to clarify some things: https://billydm.github.io/blog/clarifying-some-things/

If you are interested in some help with the GUI, I can help

Re: Digital Audio Workstation Front End Development Struggles

#269

Post by cmrdporcupine »

redeeman wrote: post #254
cmrdporcupine wrote: post #187

Earlier quoted context omitted.

I spent some time last year building out a UI framework for VSTs based on embedded HTML/JS, after being frustrated with the terrible VST3 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's not Electron, but it's Electron-like. And it was totally fine, performance wise. Remember this is the UI layer, not the audio renderi…

so an incalculable effort was spent making chromium just tolerable, but rest assured, still far far far from any kind of random native application, in both speed and memory usage. simply opening a chromium tab with an empty html page uses more ram than my amiga had 30 years ago, and funnily enough, I was able to run applications on that maybe i will be impressed if they manage to get the chromium abomination down to…

I too from from that era of computing. That ship has sailed. There is no comparison in terms of the architectural complexity between then and now. You can decry all the layers of abstraction, and they have indeed brought amplification on the amount of memory and cycles necessary to do "simple" tasks. But they've also brought with them capabilities so far beyond what we did then.

I worked in the Chromium source tree. It is indeed massive and complicated. But I can assure you that none of us were ever "wooo let's just chew memory and CPU cycles" -- it is written with efficiency in mind all over. It's just cumulatively quite complicated what it is doing.

Can you write a GUI toolkit which throws away 99% of that cruft? Yes. But it will lack so many creature comforts that we've become used to. What we had back then.. it lacked vector fonts, it lacked GPU acceleration, it lacked transparencies, it lacked multiple DPI support, aliasing, subpixel rendering, etc.. It lacked accessibility. It lacked multiple keyboard layout support. It lacked proper multiple language support, it all predated unicode and nobody even thought about right to left text flow, etc.. Obviously no touch screen and gesture support. Hell, the Amiga widget kits barely had standardized components of much variety at all.

And that's not even bringing up the VM that runs JavaScript. Which you can bitch all you want about it -- but back then many of us salivated over Smalltalk-80 (another garbage collected dynamic late-bound OO language) but our machines could not handle it. Turns out to do that kind of system well and at scale, you need resources far beyond 80s and 90s computers. We're there now, but it took a long time.

All of this costs in software complexity.

Finally, memory usage is also a lot more complicated than it used to be. Firstly, we have so much more of it than before so we can do a lot more trading off memory for speed than we did back then, when memory was stupidly expensive. Secondly, buffer management and allocation can have all sorts of subtleties esp in the context of virtual memory. Something can show in top as using X memory, but the actual mount of memory pages in physical use and currently paged into the application may not be anywhere close to that. In a virtual memory system, memory accounting is a tricky subject.

Shit is not out of control. It's just a lot more complicated on the surface than you're willing to admit.

Re: Digital Audio Workstation Front End Development Struggles

#270

Post by modeless »

andrewmcwatters wrote: post #243
modeless wrote: post #67

Earlier quoted context omitted.

"Immediate mode" is a description of the API, not the implementation. It's not a lie to cache state under the hood. In fact it's sensible and doesn't defeat the point at all.

This is incoherent. The implementation is shaped by API limitations. Immediate mode APIs that hold data on the GPU are not immediate, they're by definition retained.

The people who actually make immediate mode GUIs disagree with you. https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...
Post reply on HN