On Fri, Apr 13, 2012 at 1:47 AM, Per Nyblom <perny843@hotmail.com> wrote: > Hello, > > it would be great to be able to access the generated sound data without > having to send it to the speakers as well. > This feature is very useful for a musical application that should render a > wav-file or similar (perhaps with the help of the FileSystem API). Most > existing musical applications support this "offline" rendering mode. > > It is also useful to be able to create AudioBuffers as an optimization of > a graph. Suppose that you create a very large graph that generates a sound > effect or musical instrument sound and want to reuse it. It is very > convenient to be able to generate AudioBuffers to improve performance > without having to do this with an external program. > > All this could perhaps be supported by using a subclass of AudioContext > that supports methods like: renderToBuffer(AudioBuffer, bufferOffset, > length) or something similar. > It is important to be able to incrementally render to the buffer because > of the single-threaded nature of JS (you can use Workers for this but I > think it is important anyway). > Won't a JavaScriptNode work for this, where the node just saves the data away in an audiobuffer? Or are you saying it won't work because JS is single-threaded? RayReceived on Monday, 16 April 2012 19:11:04 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 16 April 2012 19:11:05 GMT