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

231–240 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#231

Post by KaiserPro »

phkahler wrote: post #148
gattis wrote: post #147

Not the coolest answer but I feel like QT is gonna be hard to beat here. It has a ton of this functionality already, signals are not the enemy for something this complicated and time-driven, it runs on anything and performance is great, and its pretty powerful/flexible when you need to whip up custom graphics stuff. QML and JS are really nice to have. I wrote a modular synthesizer GUI with it ( https://github.com/ohm…

I'm not QT or any other gui toolkit is well suited for this. Every widget is custom and many require high framerate / low latency. It's probably best to treat it like a video game and just render everything every frame. Only use gui events to affect the underlying data model, don't trigger any gui updates or rendering from them. In this light you're looking for fast software or OpenGL rendering as the key feature in…

> many require high framerate / low latency.

But that's the thing, unless you are _recording_ audio, you can cache and pre-generate the visualisation before hand. FFTs even on 24 192khz 24bit tracks isn't that taxing.

Even visualisations don't have to be that low latency. So long as the audio tracks are in sync you'll mostly be fine.

For waveforms you can literally side scroll the visualisation. You're not going to be pushing more than 60-75hz which gives you 13ms per frame at worst.

Re: Digital Audio Workstation Front End Development Struggles

#232

Post by klodolph »

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…

The “fast path” for macOS exists. I don’t know what is happening in Qt-land, but if you want to throw pixels at the screen really fast, you can do it through Core Animation. You can feed it a buffer of pixel data.

My experience is that this is extremely fast.

Re: Digital Audio Workstation Front End Development Struggles

#233

Post by gattis »

phkahler wrote: post #148
gattis wrote: post #147

Not the coolest answer but I feel like QT is gonna be hard to beat here. It has a ton of this functionality already, signals are not the enemy for something this complicated and time-driven, it runs on anything and performance is great, and its pretty powerful/flexible when you need to whip up custom graphics stuff. QML and JS are really nice to have. I wrote a modular synthesizer GUI with it ( https://github.com/ohm…

I'm not QT or any other gui toolkit is well suited for this. Every widget is custom and many require high framerate / low latency. It's probably best to treat it like a video game and just render everything every frame. Only use gui events to affect the underlying data model, don't trigger any gui updates or rendering from them. In this light you're looking for fast software or OpenGL rendering as the key feature in…

Well, QT does use GPU pipeline for all its rendering, in every backend there is, including OpenGL.

Every widget in my app above is custom as well, it was meant for a raspberry pi and a tiny touch screen. If visually customizing an existing QT widget isn't enough, you just go one or two abstractions up their tree, inherit from there, and make it do what you want using not only custom code but you can grab from many smaller QT parts. For instance in my app you grab cables out of modules and plug them into other modules, which is not a common UI thing. You just grab some of QTs bezier shape rendering stuff and draw the cables with it, and it was trivial to add gravity and make the cables springy.

It's these tools and maturity that are going to end up making your life easier on a project like this. If you go with a young framework that exists just because some sassy guy is very opinionated about how you should be forced to manage things like state and mutability, you will end up having to ram things in, and mostly working from scratch.

Re: Digital Audio Workstation Front End Development Struggles

#235

Post by elevaet »

deckard1 wrote: post #227
elevaet wrote: post #219

This post really makes me appreciate the engineering that led to the completely usable and powerful DAWs that ran on the comparatively weak hardware of the late 90s, early 2000s like Cakewalk, Cubase, Logic.

and without GPUs, mind you. And a lot of that trickery probably came down to: let's write everything in assembly. Fruity Loops was absurdly fast in the early 2000s and was written in Delphi and assembly, IIRC. In 2023 DAWs should not be that difficult to make fast. It's a solved problem. Multi-channel audio processing is one thing that modern CPUs should not even break a sweat at. I believe this article has uncovered…

Oh yes, thanks for the reminder about Fruity Loops, another great piece of software from that era.

Not a DAW, but I really miss CoolEdit

Re: Digital Audio Workstation Front End Development Struggles

#236

Post by lelanthran »

toastal wrote: post #56
zorr wrote: post #52

I have a feeling desktop development is going to slowly revert back to classic OOP paradigms just like the web world detoured from MPA -> SPA -> SPA+SSR -> back to something that looks a lot like MPA again. Classic toolkits like GTK, Qt, UIKit/AppKit, Swing and JavaFX use OOP to solve some of the problems this article talks about. However, this OOP model seems to be somewhat incompatible with Rust's strict memory saf…

I think we need other UI models instead of everything mature being object-oriented-oriented. Doing UI work in FP (or FRP) is great in many aspects until you need to integrate with these OO models like the DOM, et.al. Direct integration or a first-class VDOM-like model would be a nice step. There’s a tangent issue with all of popular game engines built around objects.

Is there a practical functional model for GUIs?

If something doesn't exist, maybe the reason is "it's a poor fit".

If you're going to assert that FP is a better fit for GUIs, you need some demonstration of that, especially since it's been decades since this meme started.

Re: Digital Audio Workstation Front End Development Struggles

#237

Post by lelanthran »

jupp0r wrote: post #27

It's kind of funny how the author dismisses web technologies while complaining about redundant rerenders in Rust GUI libraries. This is all solved in browsers, both on the rendering engine and on the web framework library levels. Yes you need to pay attention to performance, but the premise that "web is slow" has been disproven so many times already. Just because it's really easy to write apps that are slow (and thus…

> but the premise that "web is slow" has been disproven so many times already.

That's news to me. Do you have a link comparing local non-electron apps with local electron apps?

I mean, a gui chat app I wrote a while back using libpurple(or something with that name, could have been libpigeon), without even trying, started up and loaded all cached chats faster than I could measure at the time (under 10ms).

None of the current electron-based chat apps I use right now take less than 5s even on hardware (M1 MB) that is literally 15 years ahead.

Re: Digital Audio Workstation Front End Development Struggles

#239

Post by cyclotron3k »

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

While reading the original post, I kept thinking about Nanite

Re: Digital Audio Workstation Front End Development Struggles

#240

Post by EyeSayUntoThee »

gizajob wrote: post #214
JSavageOne wrote: post #116

Earlier quoted context omitted.

What a toxic and stupid comment. Hey guys Windows already exists, why build another operating system? /s

Yeah but it's a rule of programming laziness and hubris as outlined by ESR and Larry Wall, that you don't need to keep inventing tools that already exist. There's better things to programme. This dev isn't going to build a better Ableton on his own, and this site now simply lists all the reasons he can't, not problems to solve on his own. It will take magnitudes more than $500 of his time to replicate anything close…

Ableton isn't open source. There are also several other DAWs and Ableton isn't some pinnacle of software engineering. Take Larry and ESR and anyone else with some pinches of salt, because accepting some proprietary implementations of DAWs as a tombstone on the FOSS development of DAWs is rather reductionist to the point of being totally wrong.

Why would you bother posting such a comment?

Your notion that all questions regarding how to do the manifold tasks a DAW are resolved is specious, and you couldn't possibly prove it to be true because it's false. Ableton has managed to make a product that solves the DAW questions in one particular way, and it's a black-box to boot, so that's not in the public domain, as Meadowlark is.

The technical questions entailed in Rust trying to mate with GUIs are EXTREMELY UNSOLVED AND RELEVANT RIGHT NOW! Let me tell you, state, state, state.

I can't even propose that you work for Ableton as they are classier than this! Their product is a good and useful DAW for many people, you bet. Your point is?

Post reply on HN