5 ms·

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 r

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 hit the right notes. Dump the voice instrument and your voice recording into Melodyne and drag the voice to match the notes on the voalc tone track. Now set up a link from your Melodyne track into a protools track. Then go wild, play around, apply filters, do fun stuff. You might get stuck in the fun for a week and it'll keep you awake late. Once you're done, think about doing all that on a web page or a web page pretending to be a local app. Then reread your comment. Oh by the way, you will need to install a new raw driver for your soundcard. You see, something like a 5ms audio latency you get from you normal windows sound driver, is too slow. Give some thought on how slow doing anything in JS is going to be, if a native hardware driver is too slow.

text0404 3y ago
the article is about the _UI_ for a DAW, not the core engine. the UI isn't concerned with audio analysis or applying filters or raw drivers for soundcards. it's just a visual representation of state.
jupp0r 3y ago
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.
- TheOtherHobbes 3y ago
  A DAW is going to be doing far more audio processing on tens or hundreds of channels simultaneously, while playing back some of the audio from disk, some from memory, some from live inputs, and also receiving, processing, and recording/playing MIDI events. And hosting both the audio and GUIs of third party plugins.
  - jupp0r 3y ago
    That makes sense, but what does that have to do with how GUI is implemented?
    - zigzag312 3y ago
      DAW's GUI needs to remain responsive with minimal and consistent latency. If DAW users complained because of DPC latency introduced by Nvidia's video driver, you can imagine how critical low-latency requirements are. DAW can use pretty much all of system resources (RAM, CPU, disk IO) during playback. If any other thread steals CPU for for too long during playback, like GC of an UI thread, this can introduce audio clicks/pops. Video conferencing app has tons of network latency which helps to hide other latencies. That kind of latency would be unacceptable in a DAW. Video conferencing app also doesn't starve system of resources like DAW can, so it's UI can be more resource-intensive.
- akdor1154 3y ago
  > This is in production right now as far as I know and adds very little latency. How much? As GP said, > 5ms is instant disqualification. And that is for your whole app, not just the effects pipeline. GP is right, go use a DAW in a serious setting for a while to build up an intuition of the needs of these users.
  - jupp0r 3y ago
    How is audio processing relevant to how you build the GUI?
- laratied 3y ago
  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.
  - jupp0r 3y ago
    I have not heard a single argument why DAW software can not have a web GUI. Do you have any? I'm genuinely curious.
    - EyeSayUntoThee 3y ago
      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...
- throw_m239339 3y ago
  > 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 < 10ms like Cubase or Logic and see how it goes. 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.
  - jupp0r 3y ago
    I'm not sure how any of this is relevant with regards to how you build your GUI. If you have special requirements that require you to do your audio processing in native code using low level system sound APIs then there is nothing preventing you from doing so while still building web based GUI on top of it.
    - throw_m239339 3y ago
      I'm not sure how any of your video app doing some light sound processing is relevant to the performance required for a DAW at first place either.
- duped 3y ago
  > This is in production right now as far as I know and adds very little latency. Latency in a DAW isn't just at a premium, it's configurable and needs to be reported and compensated for. That means if any audio processing adds latency, all other processing units must compensate with their own internal (or external) delays to avoid the signal going out of phase.
  - jupp0r 3y ago
    What do you think happens with multiple audio and video streams in a video conferencing use case? Apart from that, I don't see how any of this is relevant to how you build the GUI for a DAW.

text0404 3y ago

the article is about the _UI_ for a DAW, not the core engine. the UI isn't concerned with audio analysis or applying filters or raw drivers for soundcards. it's just a visual representation of state.

jupp0r 3y ago

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.

TheOtherHobbes 3y ago
A DAW is going to be doing far more audio processing on tens or hundreds of channels simultaneously, while playing back some of the audio from disk, some from memory, some from live inputs, and also receiving, processing, and recording/playing MIDI events. And hosting both the audio and GUIs of third party plugins.
- jupp0r 3y ago
  That makes sense, but what does that have to do with how GUI is implemented?
  - zigzag312 3y ago
    DAW's GUI needs to remain responsive with minimal and consistent latency. If DAW users complained because of DPC latency introduced by Nvidia's video driver, you can imagine how critical low-latency requirements are. DAW can use pretty much all of system resources (RAM, CPU, disk IO) during playback. If any other thread steals CPU for for too long during playback, like GC of an UI thread, this can introduce audio clicks/pops. Video conferencing app has tons of network latency which helps to hide other latencies. That kind of latency would be unacceptable in a DAW. Video conferencing app also doesn't starve system of resources like DAW can, so it's UI can be more resource-intensive.
akdor1154 3y ago
> This is in production right now as far as I know and adds very little latency. How much? As GP said, > 5ms is instant disqualification. And that is for your whole app, not just the effects pipeline. GP is right, go use a DAW in a serious setting for a while to build up an intuition of the needs of these users.
- jupp0r 3y ago
  How is audio processing relevant to how you build the GUI?
laratied 3y ago
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.
- jupp0r 3y ago
  I have not heard a single argument why DAW software can not have a web GUI. Do you have any? I'm genuinely curious.
  - EyeSayUntoThee 3y ago
    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...
throw_m239339 3y ago
> 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 < 10ms like Cubase or Logic and see how it goes. 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.
- jupp0r 3y ago
  I'm not sure how any of this is relevant with regards to how you build your GUI. If you have special requirements that require you to do your audio processing in native code using low level system sound APIs then there is nothing preventing you from doing so while still building web based GUI on top of it.
  - throw_m239339 3y ago
    I'm not sure how any of your video app doing some light sound processing is relevant to the performance required for a DAW at first place either.
duped 3y ago
> This is in production right now as far as I know and adds very little latency. Latency in a DAW isn't just at a premium, it's configurable and needs to be reported and compensated for. That means if any audio processing adds latency, all other processing units must compensate with their own internal (or external) delays to avoid the signal going out of phase.
- jupp0r 3y ago
  What do you think happens with multiple audio and video streams in a video conferencing use case? Apart from that, I don't see how any of this is relevant to how you build the GUI for a DAW.