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

31–40 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#31

Post by rahkiin »

andrewmcwatters wrote: post #28
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…

The amount of effort it takes to create high-performance applications in a web environment is significant, though, and the benefits you get simply working in a faster language in a desktop environment are lost on most web developers, I think, simply because most of them don't actually do any desktop or graphics API work. They simply wouldn't know. Also UI compositors are not a solved space. If they were, people would…

Please, if someone has just that, let me know. It would be excellent for games. I do believe there are implementations of flexbox in rust.

Re: Digital Audio Workstation Front End Development Struggles

#32

Post by andrewmcwatters »

Blackthorn wrote: post #26
bsder wrote: post #15

Earlier quoted context omitted.

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

Is there somewhere that has a good guide to understanding why this is the case? I'd love to learn more about it. I imagine there's a lot more to it than a gpu's pixel fill rate, which from the marketing should be sufficient but obviously from this discussion is not.

You really don't feel this unless you do graphics programming and then it hits you like a ton of bricks.

If you want a beginner's introduction to pixel fill impact, and say, you're a web developer, try picking up a friendly graphics framework like Phaser, LÖVE, or something comparable and writing a shader that's applied to a fullscreen framebuffer, and measure the frametime that it takes to simply draw that as compared to a texture without a "default" fragment shader.

Re: Digital Audio Workstation Front End Development Struggles

#33

Post by suby »

andrewmcwatters wrote: post #28
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…

The amount of effort it takes to create high-performance applications in a web environment is significant, though, and the benefits you get simply working in a faster language in a desktop environment are lost on most web developers, I think, simply because most of them don't actually do any desktop or graphics API work. They simply wouldn't know. Also UI compositors are not a solved space. If they were, people would…

Right. The point of wanting to avoid redraws is for performance. Sure, you avoid redundant redraws in web browsers, but it defeats the point because the browser is slow compared to native, even with those avoided redraws.

Re: Digital Audio Workstation Front End Development Struggles

#34

Post by andrewmcwatters »

rahkiin wrote: post #31
andrewmcwatters wrote: post #28

Earlier quoted context omitted.

The amount of effort it takes to create high-performance applications in a web environment is significant, though, and the benefits you get simply working in a faster language in a desktop environment are lost on most web developers, I think, simply because most of them don't actually do any desktop or graphics API work. They simply wouldn't know. Also UI compositors are not a solved space. If they were, people would…

Please, if someone has just that, let me know. It would be excellent for games. I do believe there are implementations of flexbox in rust.

Yeah, it's a problem space I'd like to try to tackle again some day. Yoga et al. aren't enough.

I think people are dying for a web-based compositor in other host language environments, but don't know how to elucidate this concept because they don't know anything else.

Re: Digital Audio Workstation Front End Development Struggles

#35

Post by geodel »

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.

No it is not. Though it seems proven that even with very powerful hardware users in general have been pushed to minimal expectations. So GUIs that take seconds to start or respond on multi Ghz processors and multi GB RAMs are considered fast now.

This argument is web GUI is fast is more of "It's been proven multiple times meal kits are cheaper than buying groceries from store". Yeah, someone can find really cheap meal kits if they spend many hours on hunting a deal. But in general case grocery in store is plain cheaper for most of reasonable shoppers.

Re: Digital Audio Workstation Front End Development Struggles

#36

Post by andrewmcwatters »

grumpyprole wrote: post #29

> This performance is not a problem if the app is small or the app already redraws every frame like a video game. Seems to me like immediate mode UIs were dismissed rather too quickly. Why not update a DAW UI like a video game? It has similar realtime requirements.

Immediate mode GUIs have significant limitations. You can probably lie to your end users by saying the API is immediate mode styled, but actually retained under the hood (and I think to some degree, this already happens today with cached state), but I think that defeats the point.

Re: Digital Audio Workstation Front End Development Struggles

#37

Post by z3t4 »

You would like to use a canvas element for custom ui. A canvas is a hardware accelerated 2d library (for example Skia) where you call functions to draw lines and curves. To make a decibel gauge you would have the background face image in a buffer, then only redraw the hand line on top of it for each frame.

Re: Digital Audio Workstation Front End Development Struggles

#38

Post by usernew »

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…

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 hit the right notes. Dump the voice instrument and your voice recording into Melodyne and drag the voice to match the notes on the voalc tone track. Now set up a link from your Melodyne track into a protools track.

Then go wild, play around, apply filters, do fun stuff. You might get stuck in the fun for a week and it'll keep you awake late.

Once you're done, think about doing all that on a web page or a web page pretending to be a local app. Then reread your comment.

Oh by the way, you will need to install a new raw driver for your soundcard. You see, something like a 5ms audio latency you get from you normal windows sound driver, is too slow. Give some thought on how slow doing anything in JS is going to be, if a native hardware driver is too slow.

Re: Digital Audio Workstation Front End Development Struggles

#39

Post by rzzzt »

unboxingelf wrote: post #21
porkbeer wrote: 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.

the comments about the layout of “mixing tracks” not following design guidelines or being a standard list/tree/etc struck me. in traditional audio engineering we call them channel strips and their layout reflects the signal flow - eq knobs are typically at the top, followed by compression, fx, and so on.

Naming conventions are a mixed bag (hehe) in DAWs, since not everyone who dabbles in them is an audio engineer by trade.

- Ableton calls them "mixer controls": https://www.ableton.com/en/manual/mixing/

- Bitwig's manual does mention channel strips: https://www.bitwig.com/userguide/latest/the_mix_view/#channe...

- Adobe Audition has "track controls": https://helpx.adobe.com/audition/using/multitrack-editor-ove...

- Ardour... probably has mixing board tape and felt pen marker emulation as well, I'm late and couldn't be bothered to look up its manual.

Re: Digital Audio Workstation Front End Development Struggles

#40

Post by outsomnia »

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…

Yeah. The OP should spend a day or two making HTML5 prototypes for the key aspects and see if it's really true that it's "slow".

The UI is not the hot code, it's the audio mixing. So long as the audio mising is faultless, it doesn't matter too much if it takes an extra video frame to update the dB display.

Because there are thousands of people working to maintain the code in the browser stack every day that are on his side then.

Post reply on HN