Re: OfflineAudioContext specification gaps

On May 3, 2013, at 6:59 PM, Chris Rogers <crogers@google.com> wrote:
> 
> 
> 
> On Fri, May 3, 2013 at 3:51 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> It might work well to give startRendering() an optional duration parameter in samples. Then the OfflineAudioContext would render exactly that many samples (which must be a multiple of the block size, of course) and stop (firing some kind of notification event). Then the application could make changes to the graph and call startRendering() again to render another batch of samples.
> 
> Yes, I was thinking something like that too.  Do you think it would be necessary to call startRendering() again each time, or could it be implied that after returning from the event handler that processing would continue, repeatedly calling the notification, then finally calling the oncomplete handler?

Another advantage of something like this is that it would allow streaming of rendered audio data rather than a single buffer at the end of the render, which is something I've been asking for as a user.

Currently there's nothing in the specification that says that you can't modify the audio graph from a script processor node, so one might expect to be able to do that.  If that were explicitly allowed, I don't see why you'd need any other method of scheduling graph change events.

Thanks,
-Russell