- From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Date: Fri, 14 Dec 2012 22:12:51 +0200
- To: Marcos Caceres <marcos@marcosc.com>
- Cc: public-audio@w3.org
- Message-ID: <CAJhzemUOcJX1Fcy5RuKEqMtsgCiyNSq1zVNumezd8QpWL7o9ug@mail.gmail.com>
On Fri, Dec 14, 2012 at 10:05 PM, Marcos Caceres <marcos@marcosc.com> wrote: > > > > On Friday, December 14, 2012 at 7:55 PM, Jussi Kalliokoski wrote: > > > Hi Marcos! > > > > On Fri, Dec 14, 2012 at 9:24 PM, Marcos Caceres <marcos@marcosc.com(mailto: > marcos@marcosc.com)> wrote: > > > Hi, > > > I'm a bit confused… why does the API require a timestamp relative to > some time (i.e., performance.now())? For example: > > > > > > This is to maintain symmetry with incoming messages, which have relative > timestamps, e.g. > > > > // proxy > > input.onmessage = function (e) { > > output.send(e.data, e.timestamp) > > } > > > > Right, but that will just result in no waiting? (ie., just means 0 as > timestamps in the past don't mean anything). > Not necessarily. Some platform MIDI APIs have an internal clock and allow MIDI messages to be sent and processed ahead of time, so when you receive a MIDI message, it might not be supposed to take effect immediately. The timestamps being synchronized with DOMHRTF essentially let you leverage/emulate this feature without exposing meaningless details about the underlying API, such as its internal clock. Cheers, Jussi > What am I not getting? > > -- > Marcos Caceres > > > >
Received on Friday, 14 December 2012 20:13:19 UTC