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

111–120 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#111

Post by outsomnia »

richrichardsson wrote: post #68
outsomnia wrote: post #40

Earlier quoted context omitted.

Yeah. The OP should spend a day or two making HTML5 prototypes for the key aspects and see if it's really true that it's "slow". The UI is not the hot code, it's the audio mixing. So long as the audio mising is faultless, it doesn't matter too much if it takes an extra video frame to update the dB display. Because there are thousands of people working to maintain the code in the browser stack every day that are on hi…

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.

Re: Digital Audio Workstation Front End Development Struggles

#113

Post by SSLy »

Cthulhu_ wrote: post #50
jancsika wrote: post #18

What we need is a AAA game where the main character fiddles around on an in-game DAW in some abandoned recording studio to unlock a cool zombie-blasting weapon. That will guarantee that any widget redrawing therein happens as efficiently and responsive as possible. Maybe put it in the first level so that audio engineers can easily get to it and just hang out in that part of the game to do their work, glitch free.

I do feel like there should be more crossover between video game & GUI development; most game engines are crossplatform nowadays, GUIs in games are nothing new (and probably reinvented all the time), and everything is GPU rendered already. I've yet to see any desktop app that isn't a video game built in e.g. Unreal or Unity. I did see a colleague build a website widget (iirc it was about placing furniture or a TV in…

> I've yet to see any desktop app that isn't a video game built in e.g. Unreal or Unity.

https://arkenforge.com/

Re: Digital Audio Workstation Front End Development Struggles

#114

Post by izacus »

sirsinsalot wrote: post #43
devjab wrote: post #30

> Both Javascript and the DOM are slow, there's no changing that. The DOM isn't slow. Adding or removing a DOM node is literally a few point swaps, which isn't much more than setting a property on an OOP language object. What is slow is "layout". When Javascript changes something and hands control back to the browser it invokes its CSS recalc, layout, repaint and finally recomposition algorithms to redraw the screen.…

> I also think that the downside of frameworks like Electron is that you need to be, not only Microsoft, but the Microsoft VSC team (and not the Microsoft Teams team) specifically, to bend them to your way. I am not sure this is true, Discord as one example is pretty good. As is Slack's desktop app* *By "good" I mean, perform the task in a stable way and appear fairly 'native' in terms of UX (but not UI design of cou…

> I am not sure this is true, Discord as one example is pretty good. As is Slack's desktop app*

I think you actually need to try out an actual good native app just to see how much of a ridiculous claim that is.

Re: Digital Audio Workstation Front End Development Struggles

#115

Post by izacus »

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!

We can start with something basic like a native chat app - e.g. Telegram is a nice example of an app that doesn't lag like ass when chatting.

Or an IRC client - see for example Textual.

Re: Digital Audio Workstation Front End Development Struggles

#116

Post by JSavageOne »

gizajob wrote: post #112

You could just buy Ableton for $500 and save yourself the dev hassle. It’s already a solved problem. Why reinvent the wheel?

What a toxic and stupid comment. Hey guys Windows already exists, why build another operating system? /s

Re: Digital Audio Workstation Front End Development Struggles

#117

Post by ogoffart »

larschdk wrote: post #85
ogoffart wrote: post #54

Slint dev here. I'm a bit disappointed to see that Slint is considered a non-starter. In fact, one of our users is currently working on exactly that (a VST plugin for an audio application) and they are about to release it very soon. Unfortunately, I can't share a link until it's officially released. The author seems to dismiss declarative UI without explaining why. From my perspective, declarative is the best way to…

I find Slint's font rendering odd and somewhat off-putting. It doesn't look sharp, especially on classic 96 DPI displays. Big text look inconsistently both fuzzy and aliased, and small text has inconsistent intensity. Lack of subpixel rendering and hinting? Rounded corners look sharp in comparison.

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

Re: Digital Audio Workstation Front End Development Struggles

#118

Post by [deleted] »

zerr wrote: post #81
ogoffart wrote: post #54

Slint dev here. I'm a bit disappointed to see that Slint is considered a non-starter. In fact, one of our users is currently working on exactly that (a VST plugin for an audio application) and they are about to release it very soon. Unfortunately, I can't share a link until it's officially released. The author seems to dismiss declarative UI without explaining why. From my perspective, declarative is the best way to…

Declarative UI, even when implemented coherently within the same langauge like in Flutter and MAUI/Xamarin, so there is no need for an ugly bridge between two worlds, still leads to an unreadable nested hell. Surprisingly, an imperative GUI creation code is much more easier to read and modify.

[deleted]

Re: Digital Audio Workstation Front End Development Struggles

#119

Post by alestsurko »

For 5 years or so, I'm watching for GUI infrastructure for my imaginary audio applications. And recently I started to develop an audio application in Rust. What I learned is that there is no a single best library in any language. Also, you shouldn't rely on anything as if it even a very popular thing at the moment it can become unmaintained very quickly. So it's better to choose a satisfying solution in what available currently and abstract it as much as possible to be able to switch to something else in the future. I also did a very simple benchmarks for GUI libraries I was interested in (instantiating 10 000 rectangles, styling them and doing layout) and the leader on macOS was the browser (Tauri) with Slint at the second place. But, unfortunately, Tauri is unusable for such kind of application because of IPC. If you need to visualize your audio data, you need to continuously send it to GUI. The fastest way of communication for that would only be WebRTC, because of the sandboxing. Or you would need to go all WASM, but then you don't have access to a lot of other features you needed. As a suggestion, take another look at Qt. At very least MuseScore and Ardour use it. Also, at my opinion the most mature Rust GUI library yet is egui, not Iced. FYI, Audulus uses immediate mode GUI based on nanovg (https://github.com/audulus/vger#why). And they develop their own Rust GUI library BTW (https://github.com/audulus/rui)

Re: Digital Audio Workstation Front End Development Struggles

#120

Post by syntheweave »

The problem is not really in the toolkits, it's in looking at how the performance emerges from the design.

Layout is the fundamental reason why GUI updates can be expensive: if you reduce it to a more static form, layout becomes cheaper, so recomputing it frequently becomes viable, and you can start caching more results without causing trouble.

What's the reason not to use static layout? Configuration. But configuration is something the user doesn't want to do a lot of either. If that's what they spend their time on in the GUI, they aren't making forward progress on the task.

So there's actually a self-alignment: a GUI that works well is one that can stay relatively "flat" in its performance profile, too. Trying to address this at toolkit level isn't abstract enough, because the things you do want to change, you most likely will see as either "this always updates every frame" or "this is a user action that triggers a full recompile". That isn't something that a general purpose framework can provide - it can't know that sometimes you have a window that needs to completely recompute its layout, and other times, it will never change or even move position. It's going to provide a vocabulary that favors one or the other, but you have to provide support when you need the more exceptional of the two.

IME I usually have done fine pushing the IMGUI approach farther. The problem it tends to face is with something like a scrolling list of elements of variable size: making that list automatically line up cleanly and efficiently is quite a lot of effort. But...do you need that design? Will fixed size elements work? Or pagination?

That's the kind of thing where it's tempting to say that you do need all the features, but it can quickly fall away from any specific use-case and turn into an aesthetic preference.

Post reply on HN