The author should look at how EDA (electronic design automation) tools are built. They have many of the same challenges but they also have a lot of solutions
Digital Audio Workstation Front End Development Struggles
161–170 of 276 posts
Re: Digital Audio Workstation Front End Development Struggles
#162For 5 years or so, I'm watching for GUI infrastructure for my imaginary audio applications. And recently I started to develop an audio application in Rust. What I learned is that there is no a single best library in any language. Also, you shouldn't rely on anything as if it even a very popular thing at the moment it can become unmaintained very quickly. So it's better to choose a satisfying solution in what availabl…
> As a suggestion, take another look at Qt. At very least MuseScore and Ardour use it.
Ardour uses GTK 2, and only minimally at that: https://discourse.ardour.org/t/gtk-2-has-been-deprecated-is-...
Re: Digital Audio Workstation Front End Development Struggles
#163Earlier quoted context omitted.
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…
Until last year, I worked on a team that built an electron app for video conferencing with a double digit million user base. We did audio processing (mixing, RNN noise reduction) via WebAudio in WASM. This is in production right now as far as I know and adds very little latency. That being said, this is about GUI. No reason not to do as much native processing as your heart desires outside of your GUI layer.
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 absurd if you have never made music at all. It is exactly the problem I have had with trying to learn Maya. I can't even draw something on paper. The idea a dev with no background in the domain is going to add something to software that has been evolving from very specific domain knowledge in a highly complex and unbound domain for multiple decades is utterly absurd.
Re: Digital Audio Workstation Front End Development Struggles
#164Earlier quoted context omitted.
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…
Until last year, I worked on a team that built an electron app for video conferencing with a double digit million user base. We did audio processing (mixing, RNN noise reduction) via WebAudio in WASM. This is in production right now as far as I know and adds very little latency. That being said, this is about GUI. No reason not to do as much native processing as your heart desires outside of your GUI layer.
> This is in production right now as far as I know and adds very little latency.
You're not running 20 different tracks with compression, reverb, chorus, delay + send/return tracks + sub mixes in your app. Your app has absolutely nothing to do with a DAW. You're not taking MIDI input or running virtual instruments either. Try to do that in a browser with a latency Again, your product has absolutely nothing to do with a DAW and its constraints, so don't try to claim it's an achievement of some sort.
Re: Digital Audio Workstation Front End Development Struggles
#165> 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.…
> 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…
Surplus, which predates svelte and does much the same thing, also uses no vdom and has topped out performance benchmarks for a long time.
Re: Digital Audio Workstation Front End Development Struggles
#166Earlier quoted context omitted.
I find Slint's font rendering odd and somewhat off-putting. It doesn't look sharp, especially on classic 96 DPI displays. Big text look inconsistently both fuzzy and aliased, and small text has inconsistent intensity. Lack of subpixel rendering and hinting? Rounded corners look sharp in comparison.
It seems you may have used the FemtoVG backend, which is the default if Qt is not installed and is written in pure Rust. We offer multiple rendering backends, and you may have better results with the Qt or Skia backend, which utilize native font rendering. Additionally, a recent change made improvements to address this issue in our FemtoVG backend: https://github.com/slint-ui/slint/pull/2618
I was primarily looking at demos on the homepage.
Re: Digital Audio Workstation Front End Development Struggles
#167Building user experiences is inherently some of the most difficult software engineering there is.
It's not difficult because the existing tools are poorly made (though most of them are), it's difficult because the core problem is extremely complex (in the Rich Hickey [1] sense of the word, e.g., braided, intertwined, complected, etc.).
In order to build a user experience, we start with some information that can often (though certainly not always) appear both simple and easy (i.e., unbraided and comprehensible). But then we must create a projection of that information onto a 2D (or 3D) plane and manage it's changing state over time.
This is where everything falls apart. We're usually trying to manage a very wide, very deep, loosely defined tree of state and we're trying to reflect an arbitrary number of user interactions and mutations instantly, and over time.
Exactly zero of our tools (programming languages, UI toolkits, Operating Systems, etc.) have strong support for managing change-over-time in a way that makes this type of problem fast, stable or enjoyable to present, use, verify or mutate.
I love that the OP showed the triangle of Performance, Adaptability and Velocity. I've been framing a similar concept with teams since 2011 which I refer to as, "Fast, Stable and Delightful."
It's my thesis that we need to balance these three requirements in both our activities and in the output that we produce. This balance is incredibly difficult to achieve and harder still to maintain.
Different organizations tend to focus internal power in one of these 3 nodes (e.g., Google on Stable, Facebook on Moving Fast, and Apple on Delight). Note that the desire to move "Fast," or even to be "Stable" rarely achieves the desired result.
The only organization I've seen manage these values effectively is Apple and I believe this is because people there have understood for decades that speed and stability are prerequisites for delight, but that neither speed, nor stability (alone or together) are sufficient to make something that gives humans the sense that someone, somewhere actually cares about how they feel.
I love how the OP is exploring this problem space and how they are digging into the existing solutions and trying to define the problem with some rigor. This is fertile ground for exploring new ideas and new approaches. Please do not discourage this activity!
[1] Simple Made Easy: https://www.youtube.com/watch?v=SxdOUGdseq4
Re: Digital Audio Workstation Front End Development Struggles
#168Not 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…
Which you can do with QT. It's a bit unwieldy, but it's performant and flexible.
Re: Digital Audio Workstation Front End Development Struggles
#169Earlier quoted context omitted.
> The author seems to dismiss declarative UI without explaining why. From my perspective, declarative is the best way to describe UI. …but I mean, that’s an opinion that is not falsifiable. If the author disagrees, that’s up to them right? I agree with the author too; after using xaml, my taste for declarative UIs is limited. Here’s something that is falsifiable: what is possible using declarative UIs is a strict sub…
I'm not sure where you read "wrong". Did the message get edited?
Those are scare quotes around the word. It's not quoting the parent comment.
Re: Digital Audio Workstation Front End Development Struggles
#170Earlier quoted context omitted.
> The author seems to dismiss declarative UI without explaining why. From my perspective, declarative is the best way to describe UI. …but I mean, that’s an opinion that is not falsifiable. If the author disagrees, that’s up to them right? I agree with the author too; after using xaml, my taste for declarative UIs is limited. Here’s something that is falsifiable: what is possible using declarative UIs is a strict sub…
I'm not sure where you read "wrong". Did the message get edited?
No, sorry if my "'s made it appear I was quoting a literal text. What I mean is:
> The author seems to dismiss declarative UI without explaining why.
> From my perspective, declarative is the best way to describe UI.
I think it's pretty clear that the writer here believes that the OP is wrong about slint and declarative UIs.
My point is that OP is not wrong; declarative UI is not the best way of doing UI for all use cases.
It is simply one way of doing UI.