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

61–70 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#61

Post by chrismorgan »

andrewmcwatters wrote: post #28
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…

The amount of effort it takes to create high-performance applications in a web environment is significant, though, and the benefits you get simply working in a faster language in a desktop environment are lost on most web developers, I think, simply because most of them don't actually do any desktop or graphics API work. They simply wouldn't know. Also UI compositors are not a solved space. If they were, people would…

> 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 it looks to have grown quite interesting now.

• Blitz https://github.com/DioxusLabs/blitz> is based on from-scratch implementations of CSS layout and rendering, and wgpu rendering. It’s not usable yet, but is a very interesting concept. If one happens to be familiar with React Native: it’s kinda like that, or React Native Web.

Re: Digital Audio Workstation Front End Development Struggles

#62

Post by jerrre »

davedx wrote: post #55

I've worked on big complex UI projects that needed to run on embedded hardware, using different tech. Some of my observations over the years, if it helps: * The DOM isn't "slow" per se, but using the DOM for this kind of application is usually the wrong path to take. As soon as I need something even slightly off the well beaten path of web applications I tend to reach for canvas based solutions. * Libraries like EFL…

Regarding drawing analyzers, spectrographs:

I feel it actually has become a lot more expensive to draw individual pixels to a screen with the cpu compared to 20yrs ago.

Perhaps just because the resolutions are higher, but maybe the architecture (hardware or os) have just changed.

Re: Digital Audio Workstation Front End Development Struggles

#63

Post by chaosprint »

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…

Do you have plan for wgpu?

Re: Digital Audio Workstation Front End Development Struggles

#64

Post by samwillis »

p-e-w wrote: post #60
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…

> But there is no magic to a VDOM and speed There absolutely is. If you are using standard DOM APIs and are first changing the text of a element, then changing it back to what it was before (which can easily happen if your application logic is sufficiently complex, with multiple piecewise state changes impacting the UI), the browser will have to re-render the element twice, which means two full re-layouts unless the…

No, in a correctly implemented pure DOM manipulation app you would update the DOM once to match your state, that's faster than building a VDOM and diffing it. Modifying the DOM twice, with an unintentional reflow and redraw between, would be a bug in your code.

Yes, "if your application logic is sufficiently complex, with multiple piecewise state changes impacting the UI" is what a VDOM helps with from a developer perspective. But it isn't magically "faster".

Personally I'm a fan of reactive frameworks such as Vue that do use a VDOM, but also by using a reactive state can do fine grain partial rendering of that VDOM for efficiency.

Would I build an app without a (probably VDOM based) framework, no I wouldn't.

Also note that the "fastest" frameworks, such as Solid, don't use a VDOM, they track state changes and do fine grade DOM manipulation to match it.

Re: Digital Audio Workstation Front End Development Struggles

#66

Post by bradrn »

davedx wrote: post #55

I've worked on big complex UI projects that needed to run on embedded hardware, using different tech. Some of my observations over the years, if it helps: * The DOM isn't "slow" per se, but using the DOM for this kind of application is usually the wrong path to take. As soon as I need something even slightly off the well beaten path of web applications I tend to reach for canvas based solutions. * Libraries like EFL…

> for building a UI I would actually personally choose something JavaScript-based

The author does address this at [0]. Their main arguments are that web-based stuff is slow and requires lots of memory, especially when making something which runs outside a web browser.

[0] https://billydm.github.io/blog/daw-frontend-development-stru...

Re: Digital Audio Workstation Front End Development Struggles

#67

Post by modeless »

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.

"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.

Re: Digital Audio Workstation Front End Development Struggles

#68

Post by richrichardsson »

outsomnia wrote: post #40
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…

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.

Re: Digital Audio Workstation Front End Development Struggles

#69

Post by thorncorona »

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…

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.

Re: Digital Audio Workstation Front End Development Struggles

#70

Post by andybak »

> 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 Winamp skins, most of them were awful and had terrible usability. It was a garish novelty akin to "Pimp My Ride"

Post reply on HN