Digital Audio Workstation Front End Development Struggles • Hacker News Board

Re: Digital Audio Workstation Front End Development Struggles

#271

Post by klodolph » Wed, May 17, 2023, 4:51 PM UTC

davedx wrote: post #258

klodolph wrote: post #232

Earlier quoted context omitted.

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 .

Good to know about. This was also my intuition, that there must still exist ways to blast pixel data quickly, but it's not the "happy path" in modern graphics API's.

Blasting pixel data from the CPU to the GPU is normally about as "happy path" as it gets. The entire architecture is designed to make that kind of operation super efficient and super fast.

It's the opposite direction (GPU to CPU) which is a pain in the ass. Still fast if you do it correctly, but it's easy to end up with a stall.

Re: Digital Audio Workstation Front End Development Struggles

#272

Post by thomashop » Wed, May 17, 2023, 6:27 PM UTC

zorr wrote: post #255

yurishimo wrote: post #89

Earlier quoted context omitted.

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…

Imagine your keyboard lagging a few extra ms before the character you typed is visible on the screen.

Average keyboard latency is between 3-15ms depending upon the type of keyboard switches used and the connection type.

Re: Digital Audio Workstation Front End Development Struggles

#273

Post by andrewmcwatters » Wed, May 17, 2023, 9:33 PM UTC

modeless wrote: post #270

andrewmcwatters wrote: post #243

Earlier quoted context omitted.

This is incoherent. The implementation is shaped by API limitations. Immediate mode APIs that hold data on the GPU are not immediate, they're by definition retained.

The people who actually make immediate mode GUIs disagree with you. https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...

ocornut's own bulletpoints are incoherent. He can call it whatever he wants, it doesn't mean it's meaningful.

The fact that he's designed a retained mode library with an immediate mode API doesn't mean that it doesn't have literally the same limitations, because he doesn't expose the abstractions to you to actually do meaningful retained work.

I don't care what made up paradigm someone else has invented.

Anyone who was doing immediate mode graphics programming before shader based pipelines knows exactly what it is, because you would have used the APIs by standards organizations themselves.

Re: Digital Audio Workstation Front End Development Struggles

#274

Post by redeeman » Wed, May 17, 2023, 10:11 PM UTC

cmrdporcupine wrote: post #269

redeeman wrote: post #254

Earlier quoted context omitted.

so an incalculable effort was spent making chromium just tolerable, but rest assured, still far far far from any kind of random native application, in both speed and memory usage. simply opening a chromium tab with an empty html page uses more ram than my amiga had 30 years ago, and funnily enough, I was able to run applications on that maybe i will be impressed if they manage to get the chromium abomination down to…

I too from from that era of computing. That ship has sailed. There is no comparison in terms of the architectural complexity between then and now. You can decry all the layers of abstraction, and they have indeed brought amplification on the amount of memory and cycles necessary to do "simple" tasks. But they've also brought with them capabilities so far beyond what we did then. I worked in the Chromium source tree.…

the khtml to webkit to chromium expansion is NOT in any way defensible in contrast to amount of features. I sincerely hope that it is done due to not caring even the tiniest amount about efficiency, because the alternative is not pleasant to think about.

funnily enough some software cares greatly about efficiency, namely those where it isnt just possible to buy a bigger cpu and more ram to make it "tolerable", they manage to care about practically every single instruction, and what do we get for it? great quality of software

Re: Digital Audio Workstation Front End Development Struggles

#275

Post by throw_m239339 » Thu, May 18, 2023, 4:19 AM UTC

jupp0r wrote: post #245

throw_m239339 wrote: post #164

Earlier quoted context omitted.

> This is in production right now as far as I know and adds very little latency. You're not running 20 different tracks with compression, reverb, chorus, delay + send/return tracks + sub mixes in your app. Your app has absolutely nothing to do with a DAW. You're not taking MIDI input or running virtual instruments either. Try to do that in a browser with a latency Again, your product has absolutely nothing to do with…

I'm not sure how any of this is relevant with regards to how you build your GUI. If you have special requirements that require you to do your audio processing in native code using low level system sound APIs then there is nothing preventing you from doing so while still building web based GUI on top of it.

I'm not sure how any of your video app doing some light sound processing is relevant to the performance required for a DAW at first place either.

Re: Digital Audio Workstation Front End Development Struggles

#276

Post by JSavageOne » Mon, May 22, 2023, 6:49 AM UTC

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…

Right, so like I said in my previous comment - you are the equivalent of someone telling Linus Torvalds "Why bother creating another operating system? MS-DOS already exists".

As someone who's used various DAWs extensively, Ableton Live most certainly is not perfect. It has a terrible piano roll (see FL Studio for a good one). Many have felt the same way, but they don't fix it and there's nothing you can do about it because it's closed source.

Of course building a DAW is extremely difficult. Doesn't mean that because a closed source version already exists that it's not an endeavor worth pursuing. I personally would love for there to be a quality open source DAW comparable to the commercial ones (if I were wealthy it'd definitely be something I'd bankroll).