- From: Marcos Caceres <marcos@marcosc.com>
- Date: Sat, 15 Dec 2012 15:04:01 +0000
- To: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Cc: Chris Wilson <cwilso@google.com>, "public-audio@w3.org" <public-audio@w3.org>
Hi Jussi, Chris, On Saturday, 15 December 2012 at 10:06, Jussi Kalliokoski wrote: > On Fri, Dec 14, 2012 at 11:41 PM, Chris Wilson <cwilso@google.com (mailto:cwilso@google.com)> wrote: > > On Fri, Dec 14, 2012 at 11:33 AM, Marcos Caceres <marcos@marcosc.com (mailto:marcos@marcosc.com)> wrote: > > > > for example, if you're recording the MIDI messages from a live piano controller, you will want the subtleties of that timing recorded - you may have some lag when passing through to send(), but when playing back that recorded sequence later, your timestamps will be more precise. > > > > > > Hang on… I'm seeing what you are saying, but this seems like a strange way to achieve the desired outcome… if the idea is to hook device A to device B through some communication port (in this case we are using send), then it's better to do this directly. At the moment, we have basically this: > > > > > > input.addEventListener("message",function(e){output.send(e.data)}) > > > > > > When what we really want is: > > > > > > input.connect(output); > > > > > > So you can bypass the JS layer and get realtime communication. > > > > No, you're misunderstanding what I'm saying - it's rare, IMO, that you would want to do this. That's my point - most of the time, you will be recording and processing that data, but frequently you'll be recording it relative to a "sequence clock" - so you'll need high precision. To be clear, I'm not questioning the need for high precision. I absolutely agree with that. > > > > > Exactly. Consider you had a sequence of MIDI data pre-recorded and timestamped, and you want to play that back, but you don't want to schedule everything at once (otherwise pausing or stopping would become impossible): Ok, I think I'm getting it now :) I'll try to set up a little experiment and see if I can replicate the above (though it won't really work in the reference implementation as we are still relying on setTimeout for scheduling... which only has a precision of 4ms) In any case, I don't think I'm going to be alone on being a bit confused by this. It would be good if the spec clarified this a bit more in a non-normative way. Thank you both again for the explanations/clarifications. It's been really helpful. -- Marcos Caceres http://datadriven.com.au
Received on Saturday, 15 December 2012 15:04:32 UTC