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

91–100 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#91

Post by rob74 »

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.

That's unfortunately an issue I have seen with several new GUI frameworks over the last years: with High-DPI displays getting more widespread, they tend to push subpixel rendering support down the road.

Re: Digital Audio Workstation Front End Development Struggles

#92

Post by squarefoot »

I can't recommend a toolkit or a set of widgets because ages ago I came to the conclusion that there's no way to use traditional ones for a good DAW interface, and something very specific to the task should be developed, which is a pain in the ass. For spectrograms, I could suggest a look at Jaaa's source. It draws directly using wrappers on X11 libraries and it's fast and efficient also on low end hardware.

https://wiki.linuxaudio.org/apps/all/jaaa

http://kokkinizita.linuxaudio.org/linuxaudio/

Re: Digital Audio Workstation Front End Development Struggles

#93

Post by mort96 »

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.

Hmm? I've written a fair bit of React, which I assume fits the declarative description, and I never got the impression that it leads to an "unreadable nested hell". You split up your big functions into smaller reusable functions, just like in all other forms of programming.

Re: Digital Audio Workstation Front End Development Struggles

#94

Post by chrismorgan »

ricardobayes wrote: post #84
chrismorgan wrote: post #61

Earlier quoted context omitted.

> But no one is saying, "Hey I have a CSS 2.1 compliant rasterizer and compositor that you can use in your C++ or Rust environment!" are they? There’s actually quite a lot of interesting work going on in that general space, has been in various forms for some years. A couple that immediately spring to mind: • Azul https://azul.rs/ > builds on WebRender, as used in Firefox. I haven’t looked at it for a few years, but i…

React Native Web is a bit like scratching your left ear with your right arm :)

Actually, forget the React Native Web thing, I think I was mixing it up with something from a few years back that was more the other way round (running React web stuff on React Native, not running React Native on web).

React Native Web… eh, it has a potential place. Maybe like scratching your left ear with your right arm, because your left arm is partially paralysed, or something!

Re: Digital Audio Workstation Front End Development Struggles

#95

Post by raincole »

suby wrote: post #78
Cthulhu_ wrote: post #50

Earlier quoted context omitted.

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 have seen a handful of desktop software apps built in Godot over the years. For example, https://bauxite.itch.io/bitmapflow is an app which I've gotten value out of built in Godot.

My favorite Godot app is Material Maker (https://www.materialmaker.org/). I downloaded it when Substance Designer was acquired by Adoboe. I'd say it actually has better usability than Designer.

Re: Digital Audio Workstation Front End Development Struggles

#96

Post by jupp0r »

geodel wrote: post #35
jupp0r wrote: post #27

It's kind of funny how the author dismisses web technologies while complaining about redundant rerenders in Rust GUI libraries. This is all solved in browsers, both on the rendering engine and on the web framework library levels. Yes you need to pay attention to performance, but the premise that "web is slow" has been disproven so many times already. Just because it's really easy to write apps that are slow (and thus…

> but the premise that "web is slow" has been disproven so many times already. No it is not. Though it seems proven that even with very powerful hardware users in general have been pushed to minimal expectations. So GUIs that take seconds to start or respond on multi Ghz processors and multi GB RAMs are considered fast now. This argument is web GUI is fast is more of "It's been proven multiple times meal kits are che…

Define fast. Do you care about frame rates? input latency? startup times? memory usage?

There are trade offs, but if you care about high frame rates and low input latency, web apps can totally deliver that.

Look at https://lighttracer.org/app.html, for example.

Re: Digital Audio Workstation Front End Development Struggles

#97

Post by samwillis »

ricardobayes wrote: post #82
samwillis wrote: post #44

Earlier quoted context omitted.

> Frameworks like React with virtual DOMs help you by redrawing on every state change, which will typically both speed things up significantly and also carry you through a lot of things that would break if you were using non virtual DOM frameworks A virtual DOM based framework will not be faster than manual DOM manipulation with either vanilla JS or even JQuery. It certainly makes development easier, and massively re…

Huh? You're not doing any of this, the framework does it automatically. The virtual DOM and DOM change reconciliation makes it faster. DOM changes are really slow. The reconciliation makes sure only the parts are re-rendered which have changed. Failing that, the full screen is re-rendered. If you're doing manual VDOM building you're doing something very wrong.

> If you're doing manual VDOM building you're doing something very wrong.

Rendering a React or Vue component is building a VDOM, that's what I'm referring to. Your code is explicitly building a VDOM.

> The reconciliation makes sure only the parts are re-rendered which have changed.

Yes, and that makes development easier.

That reconciliation is only "faster" if your alternative non-VDOM code is poorly written, throwing away chunks of DOM and rebuilding from scratch.

I'm not advocating for not using VDOM frameworks, I use them, I'm advocating for understanding they are not faster than the DOM. that is a myth, and results in people misunderstanding the tools or how the DOM and browsers work.

Re: Digital Audio Workstation Front End Development Struggles

#98

Post by lelag »

modeless wrote: post #80
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.

Yeah, immediate mode seems like a perfect fit for a DAW. I see a lot of common misconceptions in the article. It seems like this is mostly an opinionated list of hypothetical issues imagined by the author, not something backed by a lot of data gathered from implementation experience.

Yes, I also agree that the author is wrong to dismiss immediate-mode toolkits. Immediate mode would be my first choice for a DAW application. I even would say it's almost a no-brainer as it makes so many things easier. You would need to be careful when rendering data-heavy widgets (ex: wavform) but the approach goes a long way with some careful planning even without necessarily implementing complex texture caching etc.

Re: Digital Audio Workstation Front End Development Struggles

#99

Post by mort96 »

rob74 wrote: post #91
larschdk wrote: post #85

Earlier quoted context omitted.

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.

That's unfortunately an issue I have seen with several new GUI frameworks over the last years: with High-DPI displays getting more widespread, they tend to push subpixel rendering support down the road.

And understandably so. Du pixel rendering only works on some kinds of displays (many modern displays don't have 3 vertical subpixels per pixel), makes the text look kinda bad due to the wonky colors, really doesn't mesh well with any sort of transparency or even coloured text, it requires that you keep 3 images of each glyph in memory to account for the 3 different sub pixel offsets. It also deeply entangles detailed knowledge of the monitor into your font rendering. You need to re-render everything and update all text any time orientation changes or the window is dragged between monitors. And how the hell do you handle a window stretching across 2 different monitors?

That's not to dismiss subpixel rendering, there is arguably a legibility improvement to trading off color accuracy for horizontal resolution, but it's really no wonder that new frameworks don't bother and that old frameworks are losing the ability to do subpixel rendering. Apple, for example, ripped out subpixel rendering from their frameworks a long time ago (before Retina displays, IIRC).

Post reply on HN