How does an NN generate audio without generating samples? The outputs are somehow interpreted as a continuous function / polynomial with tons of terms? And nobody ever once tried to not do that?
"when the research in these domains has been openly published and built upon by the community already"
Well, mega-corps like Google lobbied for a first-to-file system (America Invents), for one thing. Community shmunity; whoever has the most resources to file the most applications wins.
>I'm not losing a lot of sleep over the prospect that I'm not as "expert" in my job as a lawyer is
I actually apply this logic in reverse. After seeing how lacking many "senior" developers are - given that we now call you "senior" after just 5 measly years - I've come to realize I shouldn't put much weight in the skills of lawyers (and other professionals) who only have 5 years of experience. Since we're not lawyers (for example), it's easy for us to give them more credit than they deserve, because we don't know enough about the domain to criticize them.
After just a couple of years experience, developers can still write pathetic spaghetti code. If you're gonna high a lawyer with a couple of years under their belt, imagine them bungling your case like it's the codebase!
>There is ScriptProcessorNode but it’s deprecated and performance is not up to audio rendering standards.
On the web, "deprecated" doesn't mean you can't use it. It can take a long time for "officially deprecated by the standards" to become "I can't use it anymore" (obsoleted).
The replacement is the "AudioWorklet" interface and the purpose is to fix those exact synchronization issues. I wouldn't expect ScriptProcessorNode to disappear from the browser until the replacement is actually rolled out.
The Web Audio API started as the Audio Data API in Firefox, which was nothing but a buffer to blast samples into, then the Web Audio API was a refinement/competing standard above that extremely simplistic API (I adapted a Javascript-based .mod player to use AudioData instead of sticking an <audio> tag in the page circa 2011).
You've been able to generate and play back samples in browser (without Flash) for ~6-7 years now, they're simply making official changes to the underlying API in the hopes of improving it. "Deprecated" is just bureaucracy.
It's not reasonable to call it a refinement when it removed the central feature of the Audio Data API (feeding samples). Web Audio was a competing API, designed by a former developer of Core Audio (at Apple) once he moved to Google. They shipped it without a standardization process, at which point it became the de-facto audio API for the web.
> it removed the central feature of the Audio Data API (feeding samples)
Again, I've written actual code with both. With all due respect, I'm not sure what parallel universe you're from. (Do they spell it Berenstein on your side?)
I can pull up my Github commit from 2014 and look at where I changed my moz-compatible
> dynamicAudio.write(modPlayer.getSamples(bufferLength));
If you're unaware how Amiga .mod/.xm works, it is a REQUIREMENT that you can provide raw samples to the output source, because the samples are embedded into the file.
You can feed samples to the browser and have it play them, right here, right now, just like you've been able to for years. If you don't like the status of ScriptProcessor as deprecated and think AudioWorklet sucks, that's a whole separate issue, but you can feed samples now and you'll STILL be able to feed samples when AudioWorklet obsoletes ScriptProcessor.
>Web Audio was a competing API
I already mentioned it was a competing standard in my comment.
>They shipped it without a standardization process
The Audio Data API was one dude hacking on Firefox (David Humphreys) and then other people got interested. One of the requirements of the standards process is that there are multiple implementations in the wild. You need to throw it in your browser if you want it to ever be standardized.
And they DID standardize it early on. You can go read old copies of the W3C standard submitted by Google.
I was sad to see Mozilla's version go away but browser vendors eventually decided it was the losing implementation - including Mozilla.
Mozilla didn't HAVE to submit to the whims of others, they could have dug in their heels if they thought their version was better (see: The Video tag, and everyone who just so happens to be part of the MPEG-LA patent pool saying no to a patent-unencumbered, open video standard baked in to the browser)
