> i recognize there are latency and timing issues but they seem related to playback. No need to get into DSP issues; it's just that playback and input go hand-

> i recognize there are latency and timing issues but they seem related to playback. No need to get into DSP issues; it's just that playback and input go hand-in-hand. Think about playing a click track so that someone can enter notes (by clicking on the screen, for a simple example). If you have varying (audible) latency in your click track, the user can't hear where the beat is (ugh); secondly, even if you capture exactly when they click the screen, your next task is to map that onto when the beat fell. And if you don't know close enough to even quantize reliably, you're stuck. Next, the latency between "user clicks a note" and "audio plays selected note" needs to be pretty small -- think of the user above playing along with the beat... and so they click the screen, timed exactly when when the sense the next beat will fall. If the actual audio can't be triggered for another 200ms, it just sounds terrible. The latency I notice in the OP app is particularly bad because it seems to vary a lot -- I can click a key in a very steady rhythm, and it captures a very unsteady beat. Quantization can't really fix this problem; the delays seem to be uneven enough (and serious enough) that even if it barely managed to figure out "8th notes", mixing in some triplets or grace notes wouldn't go well. phon2 -- cool, I'll give it a try when I have a bit of free time. WRT WebMidi -- that's awesome, I hadn't seen the spec appear; I can't rely on it until there's better browser support (it looks like Firefox has only just started initial work on this, for example), but it's certainly also prove another motivator for fixing up audio timing issues all over.