W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

Re: [Web MIDI API] send() timestamp

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>
Message-ID: <49E007F1034D42D0A9DB590625A35B72@marcosc.com>
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
Received on Saturday, 15 December 2012 15:04:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:14 UTC