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

211–220 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#211

Post by jcelerier »

devjab wrote: post #30

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

> I suspect Electron specifically might actually be a pretty good framework for DAW's, considering what Microsoft is doing with VSC

VSC always feels noticeably slower to me than GTK / Qt / Win32 apps

Re: Digital Audio Workstation Front End Development Struggles

#212

Post by pxtail »

pier25 wrote: post #200
samwillis wrote: post #44

Earlier 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…

And yet, InfernoJS is faster than Svelte while using a VDOM.

I quickly glanced at the documentation and I'm greatly disappointed that concept of "circles" is not there. Devs, come on!

Re: Digital Audio Workstation Front End Development Struggles

#213

Post by talkingtab »

I have recently been using threejs (as in React-three-fiber). In the process I found myself wondering why I have been using html/css/react all this time. And if you think that is a dumb thought, let me tell you I do too. But it just won't go away.

I do understand the useFrame() issue, but still ...

Re: Digital Audio Workstation Front End Development Struggles

#214

Post by gizajob »

JSavageOne wrote: post #116
gizajob wrote: post #112

You could just buy Ableton for $500 and save yourself the dev hassle. It’s already a solved problem. Why reinvent the wheel?

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 to Ableton's functionality. I wasn't being toxic at all, just pragmatic. Pragmatism is part of knowing when to programme, and when not to.

Re: Digital Audio Workstation Front End Development Struggles

#215

Post by jcelerier »

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

It isn’t really though. If this were true rendering text would be super slow - but it isn’t. Text shaping and rendering is done on the CPU on all the major platforms and is simply highly optimized. And people throw 15 to 20 years ago like it was a long time ago - but OSX Jaguar is more than 20 years old now (that’s the version that brought the current design of 2D desktop rendering with a compositing window manager t…

> It isn’t really though. If this were true rendering text would be super slow - but it isn’t.

I wouldn't say so, I regularly profile my system or apps and text rendering is definitely one of the things that come up the most

Re: Digital Audio Workstation Front End Development Struggles

#216

Post by jcelerier »

jupp0r wrote: post #96
geodel wrote: post #35

Earlier quoted context omitted.

> 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 che…

Define fast. Do you care about frame rates? input latency? startup times? memory usage? There are trade offs, but if you care about high frame rates and low input latency, web apps can totally deliver that. Look at https://lighttracer.org/app.html , for example.

I tried opening the link and did not even have the patience to wait until "compiling shaders" was done. When I saw the buttons slowly coming up one at a time I literally laughed. Is this supposed to be a remotely good example?

Re: Digital Audio Workstation Front End Development Struggles

#217

Post by yamtaddle »

izacus wrote: post #114
sirsinsalot wrote: post #43

Earlier quoted context omitted.

> I also think that the downside of frameworks like Electron is that you need to be, not only Microsoft, but the Microsoft VSC team (and not the Microsoft Teams team) specifically, to bend them to your way. I am not sure this is true, Discord as one example is pretty good. As is Slack's desktop app* *By "good" I mean, perform the task in a stable way and appear fairly 'native' in terms of UX (but not UI design of cou…

> I am not sure this is true, Discord as one example is pretty good. As is Slack's desktop app* I think you actually need to try out an actual good native app just to see how much of a ridiculous claim that is.

We did some pen & paper gaming over the pandemic in Discord and its most notable feature was draining any battery you threw at it in like three hours flat—best case. All I can figure is it was sitting there calculating digits of Pi in a hot loop, or mining Bitcoin or something.

Re: Digital Audio Workstation Front End Development Struggles

#218

Post by rikarendsmp »

ruuda wrote: post #6

It's weird that the article mentions Makepad, but somehow fails to observe that Makepad's primary demo application is actually a software synthesizer. Go watch some of Rik Arends' talks! Most recently this one from RustNL last week: https://www.youtube.com/watch?v=9Q4yNlbfiYk (first talk of the day).

It's ok, we have been pretty quiet. Our primary launch goal is to have a full visual designer/IDE, not really push the UI framework stand-alone. However progress is happening and we are getting closer to that point as you can see in the talk above.

Re: Digital Audio Workstation Front End Development Struggles

#220

Post by weinzierl »

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.

Reaper, let's not forget Reaper. Fully blown DAW with brilliant UI in like 15 MB. Cross-platform too.
Post reply on HN