Re: [web-audio-api] (ScriptStateInteraction): Script interaction (setting and reading) of most state is underdefined (#108)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17327#0) by Olivier Thereaux on W3C Bugzilla. Thu, 07 Jun 2012 15:55:44 GMT

Comment from Chris Rogers, 18 May 2012


I'll need to add more detail into the spec. Here's my thinking:

Observing: the states MAY change during script execution. We believe we have good automated test methods for testing things such as .playbackState, and already test them today.

Modifying: I believe it's critical to have modifications to the graph state happen immediately due to the real-time nature of audio (think real-time synthesis where we have a MIDI API, playing notes in real-time). We need to respond to the "command" noteOn() (or start() given a better naming) right away as soon as we know for sure that this is what we want to happen. Any delays caused by waiting for the script thread to finish, gc, etc. will adversely affect this model and would be highly undesirable.

That said, there could be some advanced uses cases (not yet required or demanded by any Web Audio developers) where more complex and atomic changes to the graph will be necessary. For this, I propose something along the lines of:

context.beginAtomicChanges();
...
context.endAtomicChanges();

Once again, I believe I can demonstrate that these atomic changes will be rarely needed so won't overly complicate the JS code for developers in nearly all cases.
But we should support them for certain advanced cases, and will need to work out exactly the details...

Regarding your example of ConvolverNode -- I don't believe this specific example will be a problem, but I can understand your confusion because I haven't fully explained how these work. Give me some time...

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/108#issuecomment-24244256