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

101–110 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#101

Post by nologic01 »

After decades of development the GUI space feels more chaotic than ever. There are several dimensions that can become critical bottleneck in advanced use cases (performance, platform independence, ease of development, library/tool availability and maturity etc) and - as this post highlights quite clearly - it is non-trivial to chart a path.

Some of the difficulty is definitely intrinsic to the problem space. Nobody said that arbitrary complex interfaces have a license to run at lightning speeds with minimal coding on arbitrary and/or minimal hardware.

But I do have the feeling that in part the difficulty is because the different approaches (both historical and current) have been effectively islands, self-contained with no standardization or separation of concerns. E.g. I would at least hope that we would by now have an accepted universal way to describe GUI's (declarative). I think this might be one reason for the popularity of web based approaches: while html/css was made for documents not GUI's, it is at least something everybody agrees on.

Re: Digital Audio Workstation Front End Development Struggles

#102

Post by sirsinsalot »

thorncorona wrote: post #69
sirsinsalot wrote: post #43

Earlier quoted context omitted.

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

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!

Re: Digital Audio Workstation Front End Development Struggles

#103

Post by samwillis »

TylerE wrote: post #88
samwillis wrote: post #64

Earlier quoted context omitted.

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 pe…

Who needs memory safety? Just correctly use malloc and free on every possible code path. Easy and simple!

VDOM isn't the equivalent of memory safety - such as using Rust over C, its much more similar to using a garbage collected high level language - such as Python or Ruby - over C.

Your implied comparison doesn't work.

Re: Digital Audio Workstation Front End Development Struggles

#104

Post by ricardobayes »

samwillis wrote: post #97
ricardobayes wrote: post #82

Earlier quoted context omitted.

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, throwin…

Yeah I definitely agree with VDOM doesn't necessarily speed up anything on its own. There are many frameworks that benchmark better than react, for example - svelte, lit - these don't have VDOM at all.

Re: Digital Audio Workstation Front End Development Struggles

#105

Post by andyjohnson0 »

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…

> From my perspective, declarative is the best way to describe UI

I agree.

It seems like we have some good solutions for declaratively describing the structure and static appearance of UIs - but beyond things like transition animations, we don't have anything that satisfactorily describes their behaviour. Its a hard problem nut I sometimes wonder why this aspect is under-served by the technologies we have.

Re: Digital Audio Workstation Front End Development Struggles

#107

Post by ogoffart »

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.

I respectfully disagree. In my experience, Declarative UI is more concise, making development and changes easier. It enhances productivity and allows for a clear separation of concerns, which is beneficial.

Moreover, Declarative UI enables the development of powerful tooling and visual editors. For instance, in Slint, we have an extension that provides live UI preview and code transformation capabilities. 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.

Re: Digital Audio Workstation Front End Development Struggles

#108

Post by cannam »

jerrre wrote: post #62
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.

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 on other platforms - and I don't want to argue the details here, but I think the basic principle that you really want to avoid CPU in the frame update is sound. Preparing things on a non-time-critical path via CPU should be another matter however, there's quite a lot of capacity there.)

Re: Digital Audio Workstation Front End Development Struggles

#109

Post by rob74 »

mort96 wrote: post #99
rob74 wrote: post #91

Earlier quoted context omitted.

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…

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

Re: Digital Audio Workstation Front End Development Struggles

#110

Post by dagw »

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…

It's like going into a restaurant and expecting to participate in the cooking of your meal.

Lots of people expect and do this all the time. I want this cooked like this, no this, this replaced with that etc. Hell, some restaurants just put out all the food they have on a big table and say "go ahead and put together your own meal with whatever you want, we don't care", and that is many peoples favourite restaurant experience.

Post reply on HN