4 ms·

this is my point though. i recognize there are latency and timing issues but they seem related to playback. but at any given point, you know what sample is bei

this is my point though. i recognize there are latency and timing issues but they seem related to playback. but at any given point, you know what sample is being output. you also know if MIDI is being captured. isn't quantization just an exercise of mapping the input to a quantized sample? which is just a matter of rounding assuming you know your samplerate. ie. if there are 1000 samples in a measure (entertain me), and you quantized to 1/4, and you capture MIDI while sample 700 is being output, you just map the note to the 750th sample. what am I missing? just want to be clear my curiosity is genuine, I don't have a deep understanding in dsp or signal analysis or anything. my only knowledge of this stuff is just barely making it work for me. so I'm wondering what I'm missing :) phon2 is definitely worth a try but I just realized the demo link wasn't working. if you're familiar with grunt it should be a quick setup though :) I also realize a server component for midi is not what anyone had in mind; but the web midi api wasn't implemented at the time I needed a solution.

jtheory 12y ago
> 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.
- catshirt 12y ago
  thanks for such a thoughtful response. I totally grasp the complexity of the issue now. I guess my confusion then lies in the history that I've never had such drastic playback inconsistency in my applications- so midi input synchronization seemed consistent. I wonder if this has something to do with lack of complexity in my applications. like you suggested I should definitely read up on these playback issues and why and when they're occurring.

jtheory 12y ago

> 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.

catshirt 12y ago
thanks for such a thoughtful response. I totally grasp the complexity of the issue now. I guess my confusion then lies in the history that I've never had such drastic playback inconsistency in my applications- so midi input synchronization seemed consistent. I wonder if this has something to do with lack of complexity in my applications. like you suggested I should definitely read up on these playback issues and why and when they're occurring.