Live data from Hacker News

Digital Audio Workstation Front End Development Struggles

billydm.github.io

11–20 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#11
post #2

Its weird to see the impressions of someone who has apparently never used the equipment used in music production trying to talk intelligently about said devices. So many incorrect assumptions its really painful to read as someone aquainted with audio engineering. Interesting window into how the devs see it nonetheless.

Huh? The author wasn’t talking about audio engineering, so I don’t see how that is relevant. The GUI programming issues they’re discussing would be true for any realtime application. The fact they are building a DAW is a bit beside the point otherwise.

Re: Digital Audio Workstation Front End Development Struggles

#12

I actually know this space fairly well, probably better than most, because being an implementor of a UI compositor raises some difficult technical challenges with respect to UI tree backing layers and draw invalidation. I'm still not actually sure what the state of the art on these matters is after having researched this for years, and I suspect even what we do today across software like web browsers, video game UI i…

> I'm not sure even operating systems do Oddly enough Windows used to be a lot better at what you describe than it is (in practice) today. I've used old systems where it took 0.5sec to clear the screen, and you could see the color sweep down the monitor from top to bottom. Now THAT is slow. Because of that the OS used a lot of tricks to minimize drawing, such as xoring the caret, and precisely tracking dirty regions…

I think you're right. It used to be practice to limit your invalidation rect/region based on known bound information. Now every developer treats their entire buffer as a cheap throwaway and they couldn't be further from the truth.

Re: Digital Audio Workstation Front End Development Struggles

#13
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://glicol.org/

The biggest issue with EGUI is that the style seems to be quite fixed. The default style looks great for some customisation would be more ideal in some context.

although we are not there yet, it's great to see more and more attempts for audio /gui in rust. And I really feel that Rust is the best choice for the audio backend now.

Re: Digital Audio Workstation Front End Development Struggles

#14
post #2

Its weird to see the impressions of someone who has apparently never used the equipment used in music production trying to talk intelligently about said devices. So many incorrect assumptions its really painful to read as someone aquainted with audio engineering. Interesting window into how the devs see it nonetheless.

It seems like the level of experience of the average poster here has been decreasing steadily over time.

Re: Digital Audio Workstation Front End Development Struggles

#15

I actually know this space fairly well, probably better than most, because being an implementor of a UI compositor raises some difficult technical challenges with respect to UI tree backing layers and draw invalidation. I'm still not actually sure what the state of the art on these matters is after having researched this for years, and I suspect even what we do today across software like web browsers, video game UI i…

> Pixel fill is expensive.

And how. People don't realize that even with modern graphics card bandwidths, windows that are a good fraction of a 4K monitor take a remarkable amount of bandwidth to clear and fill.

Re: Digital Audio Workstation Front End Development Struggles

#16

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 just don't get that.

Re: Digital Audio Workstation Front End Development Struggles

#17
oh hey this is a topic i know of somewhat by chance :) i recently challenged myself to make a daw in the fewest lines of code and i came up with a cli based tracker that essentially does this:

- load track.csv

- each column corresponds to 1.wav, 2.wav, 3.wav, 4.wav etc

- for each line, parse the cell of each column for characteristics and play the sound according to those characteristics (i just did on/off with an x, but you could do volume or duration)

- delay before the next line for BPM

what i ended up was a fun little toy csv-tracker. i was convinced it would be too stupid to be fun beyond the task of making it, but as soon as i saw the 'notes' scrolling line by line.. ooo-weeee what a rush of nostalgia 10/10 would recommend as a fun exercise.

Edit: to actually respond to the article though, because this sounded a bit like storytime, since the author was asking (possibly rhetorically), i think the author -should- stick with Rust. im not saying this due to any fanboy tendencies, 90%+ of what i write is in Go, including the tracker I mentioned above.

what makes me say that Rust is a good fit is because though it is difficult to produce code at a high velocity and with more simplicity in Rust, audio is one of the problem domains where realtime computation is a must, and Rust as compared to Go for example would excel in capable hands due to the way Rust manages resources and leans more toward realtime tasks. We're really splitting hairs here, but be that as it may, i know that it wouldn't take long to be thinking about tweaking the GC if i were doing a 'serious' daw in Go.

evidently i was not the first with this idea https://www.youtube.com/watch?v=RFdCM2kHL64

Re: Digital Audio Workstation Front End Development Struggles

#18
What we need is a AAA game where the main character fiddles around on an in-game DAW in some abandoned recording studio to unlock a cool zombie-blasting weapon. That will guarantee that any widget redrawing therein happens as efficiently and responsive as possible.

Maybe put it in the first level so that audio engineers can easily get to it and just hang out in that part of the game to do their work, glitch free.

Re: Digital Audio Workstation Front End Development Struggles

#19
post #15

I actually know this space fairly well, probably better than most, because being an implementor of a UI compositor raises some difficult technical challenges with respect to UI tree backing layers and draw invalidation. I'm still not actually sure what the state of the art on these matters is after having researched this for years, and I suspect even what we do today across software like web browsers, video game UI i…

> Pixel fill is expensive. And how. People don't realize that even with modern graphics card bandwidths, windows that are a good fraction of a 4K monitor take a remarkable amount of bandwidth to clear and fill.

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.

Re: Digital Audio Workstation Front End Development Struggles

#20
post #8

I actually know this space fairly well, probably better than most, because being an implementor of a UI compositor raises some difficult technical challenges with respect to UI tree backing layers and draw invalidation. I'm still not actually sure what the state of the art on these matters is after having researched this for years, and I suspect even what we do today across software like web browsers, video game UI i…

GTK 4, which the author mentions in their post, uses a retained rendering model so that the UI can be rendered on GPU. Widgets snapshot render nodes which are immutable and can even be cached between frames. Those render nodes are diffed to calculate the damage region automatically. That damage is then used to scissor clip in GL before the render tree is converted to shader commands. The original damage flows through…

Thank you for sharing this. I'm not familiar with how GTK renders under the hood as compared to other pieces of software.
Post reply on HN