Live data from Hacker News

Digital Audio Workstation Front End Development Struggles

billydm.github.io

121–130 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#121

DAW is so challeging! But in terms of audio effect plugins, I think EGUI is usable already. Here is a Dattorro reverb VST plugin written in Rust with egui and glicol_synth: https://youtu.be/DLFO4dXzKsg Since EGUI can be used almost every where, I also made an experimental front end for Glicol music language with EGUI: https://glicol-egui.netlify.app/ There are many features missing, compared with HTML/CSS: https://gl…

I don't think you can meaningfully use immediate-mode GUIs for anything related to compositing work. If you're creating debug UIs or basic UIs at best, you're fine. That might actually work out alright for DAWs, but if you want sophisticated user-interfaces where you can add effects to things, you need to start retaining graphics data, and so many people advocating for these old school immediate-mode GUI libraries ju…

Can you explain this point a bit more? I've always hated retained mode GUI systems and im-guis seem so much nicer to work with. But I've not made something huge with them. What do you mean by compositing in this context?

Re: Digital Audio Workstation Front End Development Struggles

#122

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…

While it's not super clear, I think TFA's issue with Slint is the markup file (new syntax, not rust, special tooling/dev environment?), not the declarative bit. After all, they didn't say anything about Iced which is also declarative.

Re: Digital Audio Workstation Front End Development Struggles

#123
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.…

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

You wrote this later and I apologise for bringing it up here:

> 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

Bur that is sort of my point. Maybe I could have been clearer about it, but my intend was to say that the VDOM frameworks are faster (or perhaps safer is the right word) for people who aren’t doing things correctly. Which among others is also me.

Re: Digital Audio Workstation Front End Development Struggles

#124
post #122

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…

While it's not super clear, I think TFA's issue with Slint is the markup file (new syntax, not rust, special tooling/dev environment?), not the declarative bit. After all, they didn't say anything about Iced which is also declarative.

Good point. I don't see the issue with a new syntax either. GUI libraries always come with their own set of large APIs and conventions, so learning a new syntax isn't a big deal. The special tooling and dev environment in Slint are optional. But if you do use them, the Language Server Protocol (LSP) allow to integrate them everywhere and provides handy features like code completion, navigation, and even a live preview.

Re: Digital Audio Workstation Front End Development Struggles

#125
post #123

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…

You wrote this later and I apologise for bringing it up here: > 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 Bur that is sort of my point. Maybe I could have been clearer about it, but my intend was to say that the VDOM frameworks are faster (or perhaps safer is the right word) for people who aren’t doing things…

No worries, and the rest of your comment (DOM actually fast, render+reflow slow, Electron good choice) is good. It just bugs me when people repeat the myth that VDOM is faster at rendering than native DOM (or not clearly explaining otherwise), it encourages people to reach for a tool they don't necessarily need.

As I have said in other comments, VDOM based frameworks are good, people should use them, but not because they are "magically" faster.

Re: Digital Audio Workstation Front End Development Struggles

#126
post #110
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 exp…

Are you disagreeing with my views on theming or just my poor choice of metaphor? ;-)

Re: Digital Audio Workstation Front End Development Struggles

#127

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…

> The author seems to dismiss declarative UI without explaining why. From my perspective, declarative is the best way to describe UI.

…but I mean, that’s an opinion that is not falsifiable.

If the author disagrees, that’s up to them right?

I agree with the author too; after using xaml, my taste for declarative UIs is limited.

Here’s something that is falsifiable: what is possible using declarative UIs is a strict subset of what is possible using imperative code.

If your declarative config is Turing complete, it’s a DSL; ie. a programming language, not declarative and you’re in “not invented here” land.

If not, the possibilities for it are a subset.

That’s provable; so, if you’re worried that your UI is too complex to easily represent with the existing declarative structure, go for code.

What if you need dynamic layouts? What if your layouts are determined at runtime by dynamically loaded plug-ins? What if your layout needs to generated differently based on themes, or screen sizes? Who knows?

It seems entirely reasonable.

The same goes for other declarative solutions and projects. Eg. Terraform.

I mean, the author literally says a) it’s a trade off for velocity, b) they’re more concerned with performance, c) the implementation in slint is not complete and d) they’re considering writing a very very low level UI library to get what they want.

…maybe, they just want different things to what you’re offering?

It doesn’t mean they’re “wrong”.

Re: Digital Audio Workstation Front End Development Struggles

#128

Earlier quoted context omitted.

I think you have failed to comprehend what a DAW actually needs to do/render, quickly.

Can you share some examples where a DAW/plugin would need to update that much visual data onscreen with almost zero latency? I'm genuinely asking someone who used to make music with orchestral/Pianos/Drum VSTs a ton a few years ago. I agree that the underlying audio should be as fast as possible, but I don't see why the UI couldn't "lag" behind by a few extra milliseconds for on screen rendering. Especially as a plug…

Live manipulatable waveforms. Think DJ decks, etc. It tends to be one of those "tearing is better than stuttering" situations so it goes against a lot of compositing assumptions.

Re: Digital Audio Workstation Front End Development Struggles

#129
post #87
post #38

Earlier quoted context omitted.

Alright, here's I want you to do. It'll be interesting and fun, you'll make something cool, it's free, and then you'll come back and look at your comment and reply with a "/s." Download pirated copies of protools and melodyne, and a bunch of virtual instrument libraries from torrents. Download a midi file for a song you like, dump it into protools. Record yourself singing, right on the PC or headset mic - no need to…

Until last year, I worked on a team that built an electron app for video conferencing with a double digit million user base. We did audio processing (mixing, RNN noise reduction) via WebAudio in WASM. This is in production right now as far as I know and adds very little latency. That being said, this is about GUI. No reason not to do as much native processing as your heart desires outside of your GUI layer.

A DAW is going to be doing far more audio processing on tens or hundreds of channels simultaneously, while playing back some of the audio from disk, some from memory, some from live inputs, and also receiving, processing, and recording/playing MIDI events. And hosting both the audio and GUIs of third party plugins.

Re: Digital Audio Workstation Front End Development Struggles

#130
post #62
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.

Interesting. To be fair it's not something I've experimented with personally - I'm just extrapolating based on pure CPU clock speeds.

I have definitely encountered the issue that it's hard to draw pixels using many modern graphics API's, but I would have thought there was a way to make it fast.

I guess it depends on what you're drawing and what the primitives are too. Interesting topic, and another reason making a DAW must be a fun project!

Post reply on HN