On 14 Aug, 2012, at 3:07 AM, Chris Rogers <crogers@google.com> wrote:
> The idea of using a specialized audio "shader" language is an attractive one. I'm not sure that WebCL is the right language because there are some security issues surrounding it, and I think its future is unclear. If we look at some other choices, there are other audio languages that have been developed over the decades. You mention Chuck, but there's also CSound, SuperCollider, Faust, MPEG-4's SAOL, and others.
>
> In some ways SAOL (or a stripped down version of it) seems like the type of thing we would want. If such a language were chosen, then it would have to be shown to be totally secure to run in a browser environment. Going through the process of specifying the language and writing the run-time implementation would involve an enormous effort.
Yes there are many options to consider. The primary problem to solve is to get the language certified as secure for running in an RT thread/critical callback.
> That's why the idea of processing in JavaScript is so attractive, because it's a language that web developers know, has solved the security issues, and has implementations on all the browsers already. Unfortunately, it's not as well suited to more real-time applications, but it's still very interesting and useful I think.
JS is attractive indeed, but at the moment the poor composeability of the non-RT JS audio nodes masks any familiarity benefits that writing custom processing in JS might offer. The developer needs to be concerned with buffer sizes for JS nodes which can be different for different nodes, work out how to give them enough time often enough, etc. Abstracting those details away is worth it in just the same way as pixels and viewports are abstracted in WebGL. Furthermore, it may be possible to have a JS subset that can be safe to use in critical callbacks.
If we have a list of security concerns to address (like for WebGL), and some sense of trading off a bit of flexibility for the ability to have RT JS audio nodes that compose well with native nodes, maybe we can give such a DSL a shot (based either on JS or any other language). In any case, a useful criterion for working out this part might be to have the custom processing mechanism of choice emulate the native nodes in functionality.
Best,
-Kumar