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

171–180 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#171

Post by Capricorn2481 »

syntheweave wrote: post #120

The problem is not really in the toolkits, it's in looking at how the performance emerges from the design. Layout is the fundamental reason why GUI updates can be expensive: if you reduce it to a more static form, layout becomes cheaper, so recomputing it frequently becomes viable, and you can start caching more results without causing trouble. What's the reason not to use static layout? Configuration. But configurat…

> But configuration is something the user doesn't want to do

I guess you don't make music, which is what this post is about. If people didn't want configuration, they would use Audacity and just record. How are you going to paginate a synths oscillator? Volume meters?

Re: Digital Audio Workstation Front End Development Struggles

#172

Post by Capricorn2481 »

lolrustards wrote: post #134
toastal wrote: post #56

Earlier quoted context omitted.

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.

Even Lisp programmers decide to pragmatically use an OOP model when doing GUIs. The idea of using FP for everything is about as sensible as the paradigm of using OOP for everything.

You say that like CL programmers are inherently functional, which has never been true. They have always embraced OOP when needed

Re: Digital Audio Workstation Front End Development Struggles

#173

Post by riceart »

jerrre wrote: post #62
davedx wrote: post #55

I've worked on big complex UI projects that needed to run on embedded hardware, using different tech. Some of my observations over the years, if it helps: * The DOM isn't "slow" per se, but using the DOM for this kind of application is usually the wrong path to take. As soon as I need something even slightly off the well beaten path of web applications I tend to reach for canvas based solutions. * Libraries like EFL…

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 to Mac OS X)

Re: Digital Audio Workstation Front End Development Struggles

#174

Post by duped »

ogoffart wrote: post #54

Slint dev here. I'm a bit disappointed to see that Slint is considered a non-starter. In fact, one of our users is currently working on exactly that (a VST plugin for an audio application) and they are about to release it very soon. Unfortunately, I can't share a link until it's officially released. The author seems to dismiss declarative UI without explaining why. From my perspective, declarative is the best way to…

Most plugin UIs are extremely simple compared to a DAW, and have the nice property that most of the time they aren't visible.

Re: Digital Audio Workstation Front End Development Struggles

#175

Post by duped »

davedx wrote: post #55

I've worked on big complex UI projects that needed to run on embedded hardware, using different tech. Some of my observations over the years, if it helps: * The DOM isn't "slow" per se, but using the DOM for this kind of application is usually the wrong path to take. As soon as I need something even slightly off the well beaten path of web applications I tend to reach for canvas based solutions. * Libraries like EFL…

I've done some spectrogram stuff in the past, and the bottleneck (eg in JUCE where you'd want to do this kind of thing) is in the path rendering. It's pretty cheap to compute a big FFT, even throwing it on separate thread if you care enough for that. Rendering an anti-aliased path that looks decent on a small display panel with the basic vector path tools however isn't great.

Not saying it can't be done, because people do it. But making something that compares to the latest/greatest and is fast isn't obvious.

Re: Digital Audio Workstation Front End Development Struggles

#176

Post by phkahler »

carlmr wrote: post #168
phkahler wrote: post #148

Earlier quoted context omitted.

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…

Which you can do with QT. It's a bit unwieldy, but it's performant and flexible.

>> Which you can do with QT. It's a bit unwieldy, but it's performant and flexible.

Not doubting that it can be done with QT, but I don't think QT is really optimal either. SDL is ideal for the rendering, but has none of the regular toolbars and such, and IIRC no multi-window support. I'd actually recommend GTK for this one, since it is lighter weight and the application doesn't need a ton of actual toolkit functionality.

Re: Digital Audio Workstation Front End Development Struggles

#177

Post by FpUser »

samwillis wrote: post #64
p-e-w wrote: post #60

Earlier quoted context omitted.

> But there is no magic to a VDOM and speed There absolutely is. If you are using standard DOM APIs and are first changing the text of a element, then changing it back to what it was before (which can easily happen if your application logic is sufficiently complex, with multiple piecewise state changes impacting the UI), the browser will have to re-render the element twice, which means two full re-layouts unless the…

No, in a correctly implemented pure DOM manipulation app you would update the DOM once to match your state, that's faster than building a VDOM and diffing it. Modifying the DOM twice, with an unintentional reflow and redraw between, would be a bug in your code. Yes, "if your application logic is sufficiently complex, with multiple piecewise state changes impacting the UI" is what a VDOM helps with from a developer pe…

I do not use any frameworks for browser based JS/HTML front ends. Just plain JS and some domain specific libs when needed. No problems so far and the resulting GUIs are fast.

Re: Digital Audio Workstation Front End Development Struggles

#178

Post by p0nce »

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…

Unfortunately modern macOS renders everything at 5k and downsample, the rendering could do pretty significant stuff (like, extend bitdepth to 16-bit, color lookup to AppleRGB, trim bitdepth, with threads!) behind your back when using non-Metal, and it is buggier than before too. This stuff is way more expensive that CPU rendering itself.

Re: Digital Audio Workstation Front End Development Struggles

#180

Post by PaulHoule »

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

The DOM is fast for the kind of applications that most people create with React: sign-up forms, shopping carts, blogs, and other web sites that people used to be able to create before React using HTML directly but that web developers now look at like Stonehenge or the Egyptian Pyramids.
Post reply on HN