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…
Digital Audio Workstation Front End Development Struggles
121–130 of 276 posts
Re: Digital Audio Workstation Front End Development Struggles
#122Slint 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…
Re: Digital Audio Workstation Front End Development Struggles
#123> 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…
> 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
#124Slint 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
#125Earlier 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…
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> 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…
Re: Digital Audio Workstation Front End Development Struggles
#127Slint 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…
…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
#128Earlier 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…
Re: Digital Audio Workstation Front End Development Struggles
#129Earlier 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.
Re: Digital Audio Workstation Front End Development Struggles
#130I'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.
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!