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

251–260 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#251

Post by jupp0r »

lelanthran wrote: post #237
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…

Is latency of loading the app really relevant in the digital audio workstation use case? (no). As long as you get good frame rates while the GUI is running and latency is reasonably low, startup performance is not that important.

Re: Digital Audio Workstation Front End Development Struggles

#252

Post by EyeSayUntoThee »

PaulHoule wrote: post #244
EyeSayUntoThee wrote: post #241

Earlier quoted context omitted.

Audio is literally a major domain where GC is a big no-go... (even a GC running in another GUI thread can be an issue if it's a stop-the-world operation) You won't find a single audio backend in a GC language. GC is obviated by Rust anyway (it's native RAII pattern involves "ownership" which allows "borrowing", things are immutable by default...) and there are ARC and Box implementations (check out Box particularly)…

In a dynamic UI you don’t know these lifetimes because they are up to the user.

Well, in the sense of "lifetimes" that I mean in terms of ownership, scope, and destruction, yes we do know the lifetime (removing a plugin-instance and de-allocation in an orderly fashion is part of a plugins API, for example)

Re: Digital Audio Workstation Front End Development Struggles

#253

Post by EyeSayUntoThee »

jupp0r wrote: post #246
laratied wrote: post #163

Earlier quoted context omitted.

I have used Cubase for 25 years. A video conferencing app is just not the same category even remotely. This is like trying to build Maya or Blender in a browser without an art background but having to deal with ms latency. I just don't see the point. I don't even like Logic because the Cubase workflow is transparent to me at this point. Even the idea of grabbing pirated DAW software to get an intuition is kind of abs…

I have not heard a single argument why DAW software can not have a web GUI. Do you have any? I'm genuinely curious.

There have been various toy DAWs the have web GUIs. I've never seen a production-capable DAW with a web GUI.

I suspect that existing web-as-native-GUI frameworks make presumptions about threading that won't work where a realtime audio callback thread piping data to other audio processing threads and back is the real show, and where the GUI may need things like updated zoom levels dirtying many waveform drawings at once requiring recalculation of peak values in viewable windows to draw the little lines that make the waveform, among other things that may make simple partitioning of systems more challenging...

Re: Digital Audio Workstation Front End Development Struggles

#254

Post by redeeman »

cmrdporcupine wrote: post #187
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 spent some time last year building out a UI framework for VSTs based on embedded HTML/JS, after being frustrated with the terrible VST3 GUI package from Steinberg. I think it showed promise, but I'm unable to continue to make progress with it: https://github.com/rdaum/vstwebview It's not Electron, but it's Electron-like. And it was totally fine, performance wise. Remember this is the UI layer, not the audio renderi…

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 a more reasonable size, compared to its 1.7GB compressed size the source is now (how is it even possible?????).. I wonder, how big was khtml when webkit forked? how big was webkit when google forked?

this shit is totally out of control, and pretending anything else is something that is quite a feat to do with a straight face, and for that, you have my admiration

Re: Digital Audio Workstation Front End Development Struggles

#255

Post by zorr »

yurishimo wrote: post #89
trollied wrote: post #59

Earlier quoted context omitted.

I think you have failed to comprehend what a DAW actually needs to do/render, quickly.

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.

Re: Digital Audio Workstation Front End Development Struggles

#256

Post by lelanthran »

jupp0r wrote: post #251
lelanthran wrote: post #237

Earlier quoted context omitted.

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

Is latency of loading the app really relevant in the digital audio workstation use case? (no). As long as you get good frame rates while the GUI is running and latency is reasonably low, startup performance is not that important.

I was responding to this:

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

So, yeah, startup duration absolutely counts.

More to the point, even while using (for example) slack you still see +500ms latencies while doing things like typing

Native chat apps had instant (sub 10ms) responses.

But, you made the claim that web being slow has been disproven, which really is news to me, so I want to see benchmarks you are referring to.

Re: Digital Audio Workstation Front End Development Struggles

#257

Post by kazinator »

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.

Less, I would say; because using OOP for everything is straightforward, just obtuse, verbose and possibly slow.

You don't have to solve paper-worthy academic puzzles to use OOP everywhere.

Using OOP everywhere has been done and probably continues to in some shops. There was a time in the 1990's when nobody was fired for using OOP everywhere.

In Common Lisp, absolutely every value you can create has a class: the class-of function is meaningful for any value. You can replace all the defun forms in a Common Lisp program with defgeneric and defmethod.

Re: Digital Audio Workstation Front End Development Struggles

#258

Post by davedx »

klodolph wrote: post #232
cannam wrote: post #108

Earlier quoted context omitted.

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 .

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.

Re: Digital Audio Workstation Front End Development Struggles

#259

Post by ogoffart »

lelanthran wrote: post #228
ogoffart wrote: post #107

Earlier quoted context omitted.

I respectfully disagree. In my experience, Declarative UI is more concise, making development and changes easier. It enhances productivity and allows for a clear separation of concerns, which is beneficial. Moreover, Declarative UI enables the development of powerful tooling and visual editors. For instance, in Slint, we have an extension that provides live UI preview and code transformation capabilities. We are also…

> We are also actively working on a visual editor that lets users drag and drop widgets. Such capabilities are difficult or impossible to achieve with imperative APIs I don't think you have ever used an imperative API, have you? I used VB, then Delphi, then C++ builder and now use Lazarus, and there's no declarative equivalent that is easier or faster than those.

In the examples you mentioned, the UI is typically described in XML or form files (.dfm), which is essentially a declarative approach, and clearly not described in imperative code. Although they may not be intended to be edited by hand, the underlying representation is still declarative in nature.

Re: Digital Audio Workstation Front End Development Struggles

#260

Post by davedx »

bradrn wrote: post #66
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…

> for building a UI I would actually personally choose something JavaScript-based The author does address this at [0]. Their main arguments are that web-based stuff is slow and requires lots of memory, especially when making something which runs outside a web browser. [0] https://billydm.github.io/blog/daw-frontend-development-stru...

Yeah so one tech stack I worked with was EFL with JavaScript bindings. That was fast and compact, even the JS stuff.
Post reply on HN