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

201–210 of 276 posts

Re: Digital Audio Workstation Front End Development Struggles

#201

Post by bitL »

jancsika wrote: post #18

What we need is a AAA game where the main character fiddles around on an in-game DAW in some abandoned recording studio to unlock a cool zombie-blasting weapon. That will guarantee that any widget redrawing therein happens as efficiently and responsive as possible. Maybe put it in the first level so that audio engineers can easily get to it and just hang out in that part of the game to do their work, glitch free.

There is a bunch of those in VR. Probably more fun than on a 2D screen in pseudo 3D.

Re: Digital Audio Workstation Front End Development Struggles

#202

Post by bitL »

phkahler wrote: post #148
gattis wrote: post #147

Not the coolest answer but I feel like QT is gonna be hard to beat here. It has a ton of this functionality already, signals are not the enemy for something this complicated and time-driven, it runs on anything and performance is great, and its pretty powerful/flexible when you need to whip up custom graphics stuff. QML and JS are really nice to have. I wrote a modular synthesizer GUI with it ( https://github.com/ohm…

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…

I think the art of creating own UIs was lost once Windows started dominating; prior to that every single game or app had to create their own GUI from scratch. It only somewhat survived in gaming.

Re: Digital Audio Workstation Front End Development Struggles

#204

Post by pkphilip »

zerr wrote: post #81
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…

Declarative UI, even when implemented coherently within the same langauge like in Flutter and MAUI/Xamarin, so there is no need for an ugly bridge between two worlds, still leads to an unreadable nested hell. Surprisingly, an imperative GUI creation code is much more easier to read and modify.

Absolutely. I actually prefer a combination of declarative + imperative code similar to how it is in Delphi/Lazarus.

The overall layout of the GUI is designed using a GUI designer and this gets saved as a "form" in a resource file which is loaded at run time and so the actual code does not have a lot of declaration of the GUI but it is read in as a stream from a separate resource file.

However, to this GUI, you can add event handlers, add or remove components at run time etc. All of this is quite clumsily done (IMHO) in frameworks such as flutter.

Re: Digital Audio Workstation Front End Development Struggles

#205

Post by pkphilip »

ogoffart wrote: post #107
zerr wrote: post #81

Earlier quoted context omitted.

Declarative UI, even when implemented coherently within the same langauge like in Flutter and MAUI/Xamarin, so there is no need for an ugly bridge between two worlds, still leads to an unreadable nested hell. Surprisingly, an imperative GUI creation code is much more easier to read and modify.

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…

Have you looked at tools such as Delphi, Lazarus etc and the approach used to build GUI components which can be added at build time or at runtime?

If you are interested in talking about this, do let me know.

Re: Digital Audio Workstation Front End Development Struggles

#206

Post by chris-orgmenta »

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

Agree, but ironically I find your first sentence to be auto-descriptive / equally against guidelines.

Re: Digital Audio Workstation Front End Development Struggles

#207

Post by crazygringo »

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

> What is slow is "layout".

Right. My understanding is that, as long as you're limiting lots of graphical updates to fixed-size areas, the DOM isn't really a problem.

When you resize the window it will be slow. But if you're just animating a single knob being dragged, it's totally smooth. Similarly, if you're blitting a bit array to a canvas, it's plenty fast.

The stuff someone needs to do with a DAW interface strikes me as quite perfectly suited to the DOM actually, precisely because the layout is extremely modular. You're not dealing with long strings of text that keep unpredictably wrapping and pushing elements and therefore recalculating the entire layout. It's pretty ideal, really.

Re: Digital Audio Workstation Front End Development Struggles

#208

Post by pier25 »

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 worked for some time at a large public listed US company who used JavaScript for all their big UI projects

Could you elaborate?

Did you use a custom framework or maybe something like React or Svelte? Maybe pure vanilla?

Re: Digital Audio Workstation Front End Development Struggles

#209

Post by pier25 »

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 agree web stuff is really the best way to develop UIs. Good luck making responsive stuff in C++ for example. The paradigm of HTML, CSS, and JS is extremely powerful and even allows you to use canvas, webgpu, wasm.

There are multiple commercial projects that use web dev paradigm for GUIs:

https://coherent-labs.com/

https://ultralig.ht/

https://sciter.com/

Re: Digital Audio Workstation Front End Development Struggles

#210

Post by jcelerier »

phkahler wrote: post #148
gattis wrote: post #147

Not the coolest answer but I feel like QT is gonna be hard to beat here. It has a ton of this functionality already, signals are not the enemy for something this complicated and time-driven, it runs on anything and performance is great, and its pretty powerful/flexible when you need to whip up custom graphics stuff. QML and JS are really nice to have. I wrote a modular synthesizer GUI with it ( https://github.com/ohm…

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…

I develop https://ossia.io with Qt (Widgets + QGraphicsScene + QRhi) and it works as I want it to
Post reply on HN