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.
Collaboration doesn't require a wasm based ecosystem, and in addition a was-based plugin ecosystem is ... well, i don't even know what you're talking about there to be honest. There are plugins you already cannot get on a given platform ... do you think that adding a new platform that is likely less performant and has the same "almost fully portable but not quite" characteristics is going to help or convince plugin developers to support it too?
Collaboration requires common file formats above all else. Sharing plugins is the icing on the cake, and frequently not necessary. With sufficient bandwidth, realtime collaboration with everyone using their own preferred DAW is also fairly possible.
There are lots of better word processors than Google Docs, but most of the docs I contribute to are hosted on it because it requires zero friction for a newcomer to collaborate.
What I want is the equivalent of Google Docs for audio and MIDI, with a thriving ecosystem of plugins and softsynths that everyone can use in any project with zero friction (and none of this "let me bounce that track to audio since you don't have that plugin" nonsense).
Google Docs has no plugins. Google Docs is not a tool for accomplishing a task that used to be (and to some extent still is) considered a lifelong learning experience requiring significant skill (audio engineering). Google Docs does not rely on an ecosystem of several hundred 3rd party developers providing "critical" functionality for a given project.
I'm fairly sure that you will get a relatively functional DAW in the browser very soon (some might argue that it's already here). However, it is likely to be disjoint from the pro-audio "native" world because the features required by the latter are not likely to show up in the browser for a long time (this is a prediction, and I am ready to see it prove false).
I therefore see the DAW world bifurcating into an even more broken up version of itself than we already have (where Logic doesn't run on Windows, where AU plugins are macOS only, where there's no remotely acceptable portable session file format, where there's at least 3 and maybe 5 plugin APIs that any given developer needs to consider, etc. etc.)
Bedroom producers, podcasters and others with limited needs will find a lovely new world waiting for them in the browser. Live performance, soundtrack and other large scale productions will probably remain native. Some plugins will exist for the browser (just like some do for Linux today), many will not.
> Google Docs is not a tool for accomplishing a task that used to be (and to some extent still is) considered a lifelong learning experience requiring significant skill (audio engineering)
I would argue that the lifelong learning experience has more to do with developing a good ear (and taste) than learning specific technical tools or workflows. Anything that helps experienced audio engineers collaborate with talented musicians and composers working from home is a good thing.
With regards to plugin APIs, hopefully the web-DAW community can agree on a de-facto standard based around WebAssembly, and ideally that standard would be fully open. If it is successful, the native DAWs have the option of supporting it too.
> Anything that helps experienced audio engineers collaborate with talented musicians and composers working from home is a good thing.
Right, but if you get paid to do this sort of thing and thus time-is-money, then networked-based collaboration is likely to prove more productive than reducing the toolset to what can be done in-browser. Those tools already exist, but once again are deeply fragmented.
Don't underestimate the value of asynchronous collaboration (where person A is working on the project while person B is doing something else).
Sometimes "using the absolute best tools regardless of platform" is not the thing to optimize for.
Maybe the client wants to tweak their vocal performance and get a mastered mixdown right away (using the engineer's last-used settings for the session) without waiting (or paying) for them to re-do the master.
I think you're right at least in the near term but I wouldn't be surprised to see a low-friction browser based music production tool start to rapidly build a following the way that Rebirth or Fruity Loops did in their day. Especially for electronic music the performance requirements are not that strict and easy entry and collaboration could be enough to attract a large userbase.
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)
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.