audiotool is made with Flash. And a good demonstration of the actual usefulness of Flash to develop complex applications that could be deployed online. Too bad Adobe was incapable of taking good care of that product and didn't listen the community. I'm sure WebAudio can get better, but the OP's demo still proves that it's brittle. Changing anything in the patterns stops all sounds and the sequencer has hard time keeping a consistent tempo. I'm sure it will get better but Flash was really in advance for its time as audiotool demonstrated. Well, at least now people have stopped complaining about Flash "killing their battery". They can now blame Javascript /s
I've found that a steady method for timing is by calculating the number of samples to render per "tick" and decrement the counter after each completed sample when rendering audio to the buffer in JavaScriptNode/ScriptProcessor. Eg.
Upon the counter reaching zero, the render loop actually jumps to do sequencing and effects/modulation and then resets to counter.
In my case, the tick occurs at 50Hz because that's the PAL frame clock used in Amiga and MS-DOS module trackers like Scream Tracker and FastTracker 2. Typically trackers use a "speed" setting to additionally specify the number of ticks per pattern step - usually 6.
Although you do get sample-accurate timing, you also get latency up to the size of a single audio buffer (I use 4096 samples). While this isn't really an issue when doing purely playback, it obviously is when the audio is controlled real-time (eg. MIDI).
