This is pretty cool, I'm curious if we'll see DAWs start targeting the browser as a platform. I could see Bitwig or Ableton accomplishing this. Curious if Cockos has this in their sites, given that they seem to be most active and forward thinking.
Not sure what the metric for "most active and forward thinking" is, given that Ardour already has support for websocket-based browser control surfaces, and in general releases as often or more often than Reaper.
But anyway ...
Given that we already have things like Cardinal (a FLOSSier version of VCV Rack) running directly in the browser, I expect that a wasm port of an open source DAW will likely occur within a few years. Whether that would be a good thing is a different question. Browser audio is absolutely not the ideal platform for pro-audio (if indeed it is even possible to get the required performance at all), but for "bedroom producers" and podcasters, it might be sufficient.
The problem is that many (not all, but most) DAWs are built on native toolkits (in-house or 3rd party) that assume access to a very large operating system API. Although wasm/browser-land keeps expanding, it is still quite a long way from covering all the things that the (e.g. 86) libraries relied by on a typical native DAW require from the host environment.
For collaboration between "bedroom producers", a wasm-based plugin ecosystem would be a huge upgrade from a native DAW. I hate trying to share a project and having to worry about "do they have the right plugins/softsynths installed" and other tedious technical distractions. I'd be happy to give up 50% performance (of a native DAW) for the collaboration benefits alone.
Agreed. Web apps have no business knowing what my audio config is. Instead of the OS or browser implementing a working sound picker, every single website will have to do it and all but the big ones will do it slightly wrong. Google is positioning the web for them to take over the desktop.
It's more easily explained as always wanting your web conference call to use your headset even if normally you want the browser to use something else than as a replacement for changing your OS settings.
The web is constantly positioned to takeover the desktop though, has been for many years at this point.
Ah good, I found it very confusing that Google Meet can choose an input device but not an output. I thought my headphones weren't working or something.
Kind of a pain to change it in Gnome too (why is there no output selector in the system tray? Windows has had that for decades)
Readit News
There's no chance at all I'll give a web browser based app permission to use any audio capture device on my systems.
Depending on the app though, I might not have the same reservation for playing audio.
If it's really gated on "microphone" access though, it's just not going to happen.
But anyway ...
Given that we already have things like Cardinal (a FLOSSier version of VCV Rack) running directly in the browser, I expect that a wasm port of an open source DAW will likely occur within a few years. Whether that would be a good thing is a different question. Browser audio is absolutely not the ideal platform for pro-audio (if indeed it is even possible to get the required performance at all), but for "bedroom producers" and podcasters, it might be sufficient.
The problem is that many (not all, but most) DAWs are built on native toolkits (in-house or 3rd party) that assume access to a very large operating system API. Although wasm/browser-land keeps expanding, it is still quite a long way from covering all the things that the (e.g. 86) libraries relied by on a typical native DAW require from the host environment.
The web is constantly positioned to takeover the desktop though, has been for many years at this point.
Kind of a pain to change it in Gnome too (why is there no output selector in the system tray? Windows has had that for decades)