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

151–160 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#151

Post by phkahler »

rob74 wrote: post #109
mort96 wrote: post #99

Earlier quoted context omitted.

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…

> Apple, for example, ripped out subpixel rendering from their frameworks a long time ago (before Retina displays, IIRC). ...or at least when Retina displays were still rare and expensive, probably to encourage their adoption.

Probably because just using higher resolution is easier if it's available. Taking advantage of the physical structure of a pixel seems weird to me.

Re: Digital Audio Workstation Front End Development Struggles

#152

Post by spacechild1 »

conradfr wrote: post #142
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 ;)

Naturally, Justin developed his own UI framework. Parts of it are open source: https://www.cockos.com/wdl/

Re: Digital Audio Workstation Front End Development Struggles

#153

Post by [deleted] »

cannam wrote: post #108
jerrre wrote: post #62

Earlier quoted context omitted.

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.

With CPU, totally. As an example I can look at my own Sonic Visualiser application, largely written 15-18 years ago and entirely CPU-driven. Relative to then, it's now horrible on contemporary Macs for example - it feels far slower than it did a decade ago. It just isn't what the hardware expects. (There may be an element of toolkit-platform impedance and simple poor design on my part - it uses Qt and feels quicker o…

[deleted]

Re: Digital Audio Workstation Front End Development Struggles

#154

Post by rikroots »

rerdavies wrote: post #48
andrewmcwatters wrote: post #19

Earlier quoted context omitted.

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.

They'd probably answer: you need to be using 2D FFT convolution. ;-P

When I was searching for a very fast Gaussian blur algorithm to implement into my 2d canvas library, I stumbled across some code[1] which does a magnificent job by using something called an Infinite Impulse Response[2] filter - something that comes from the world of audio, I believe?

The best bit from my POV is that the work is all done on the CPU with no need to care about webGL/shaders/etc.

[1] - https://github.com/nodeca/glur/blob/master/index.js

[2] - https://en.wikipedia.org/wiki/Infinite_impulse_response

Re: Digital Audio Workstation Front End Development Struggles

#156

Post by azangru »

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…

> 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 ... the browser will have to re-render the element twice

As far as I understand, not if this all happens within a single browser layout/paint cycle [0]

- [0] https://twitter.com/jaffathecake/status/1552242563654066176

Re: Digital Audio Workstation Front End Development Struggles

#157

Post by berryg »

Maybe this is the way forward: build a Rust SDK which does all the high-performance heavy lifting. On top of it you create bindings (using uniffi) to your favourite front-end language. And you create a frontend focusing just on the front-end stuff.

This was presented at FOSDEM 2023 by Matthew Hodgson on building Matrix 2.0. 15 minutes into the video Matthew explains the redesign of the Matrix clients for mobile. His conclusion: maybe this is ultimate stack to build mobile applications.

https://fosdem.org/2023/schedule/event/matrix20/

Re: Digital Audio Workstation Front End Development Struggles

#158

Post by zigzag312 »

jupp0r wrote: post #96
geodel wrote: post #35

Earlier quoted context omitted.

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

I tried that app expecting responsive app, but the viewport lags significantly, and when rendering, the whole UI lags.

Re: Digital Audio Workstation Front End Development Struggles

#159

Post by rob74 »

phkahler wrote: post #151
rob74 wrote: post #109

Earlier quoted context omitted.

> Apple, for example, ripped out subpixel rendering from their frameworks a long time ago (before Retina displays, IIRC). ...or at least when Retina displays were still rare and expensive, probably to encourage their adoption.

Probably because just using higher resolution is easier if it's available. Taking advantage of the physical structure of a pixel seems weird to me.

Actually, CRT monitors did "subpixel rendering" automatically when the beams hit the subpixels only partially. So using this technique on LCDs is just trying to emulate a feature that CRTs have built in.

Re: Digital Audio Workstation Front End Development Struggles

#160

Post by [deleted] »

cannam wrote: post #108
jerrre wrote: post #62

Earlier quoted context omitted.

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.

With CPU, totally. As an example I can look at my own Sonic Visualiser application, largely written 15-18 years ago and entirely CPU-driven. Relative to then, it's now horrible on contemporary Macs for example - it feels far slower than it did a decade ago. It just isn't what the hardware expects. (There may be an element of toolkit-platform impedance and simple poor design on my part - it uses Qt and feels quicker o…

[deleted]
Post reply on HN