Re: Audio-ISSUE-105 (MIDI timestamp resolution): timestamps in MIDI should use High Resolution Time [MIDI API]

Right - I knew I'd run across one last week, but couldn't remember it.
 Thanks.

On Mon, Jun 4, 2012 at 12:55 PM, Adam Goode <agoode@google.com> wrote:

> The main one I know recently is requestAnimationFrame:
>
> http://updates.html5rocks.com/2012/05/requestAnimationFrame-API-now-with-sub-millisecond-precision
>
> On Mon, Jun 4, 2012 at 3:40 PM, Chris Wilson <cwilso@google.com> wrote:
> > Has any other spec/feature depended on DOMHRTS - or more particularly, on
> > window.performance.now()?  I'm wondering if this is expected/approved/a
> good
> > idea for features like this.  (I'm envisioning that we need a new
> setTimeout
> > too at some point - would it rely on this?)
> >
> >
> > On Mon, Jun 4, 2012 at 12:36 PM, Jussi Kalliokoski
> > <jussi.kalliokoski@gmail.com> wrote:
> >>
> >> On Mon, Jun 4, 2012 at 8:41 PM, Chris Wilson <cwilso@google.com> wrote:
> >>>
> >>> I had some further discussion off-list with Chris, where he helped me
> >>> coalesce my thinking a little better.
> >>>
> >>> I think there are three design factors to a timestamp-
> >>>
> >>> What type the actual numerical value is (e.g. WebAudio's
> currentTime/time
> >>> params are double, as is DOMHighResTimeStamp - some others are long
> ints, or
> >>> long longs in Windows).  More importantly for JS devs, though is what
> the
> >>> numeric value represents: i.e., number of seconds (in WebAudio) or
> number of
> >>> milliseconds (DOMHRTS and MIDI proposal).
> >>
> >> I'd go for milliseconds as that's consistent with everything else on the
> >> web (Date.now(), setInterval, setTimeout, DOMHRTS). As to what the type
> of
> >> the number is, I'd say preferably a double (or more precise), but
> >> implementations can have different underlying optimizations and I don't
> see
> >> a need (nor do I think it's even possible) to impose further
> limitations on
> >> that. If the end developer needs just pure milliseconds and the decimal
> part
> >> will make his life harder, I hope they'll use a language that allows
> you to
> >> floor numbers, heh. :)
> >>>
> >>> What the "zero reference" (or start point) is - e.g. in WA, it's when
> the
> >>> audioContext is created, for DOMHRTS in the window.performance.now()
> usage
> >>> it's navigationStart (although by itself, the DOMHRTS type does not
> imply a
> >>> "start point" - we need to fix this if we want to use it in the MIDI
> API,
> >>> even if it's just to say it's the same as window.performance.now().)
>  For
> >>> Date.now(), the zero reference/start point is 1 January 1970 00:00:00
> UTC.
> >>>
> >>> On what clock the time proceeds.  This is somewhat subtle, because this
> >>> is really to account for different clocks possibly running on different
> >>> crystals - e.g., for WA this is the audio hardware clock. Like
> Data.now(),
> >>> the performance.now() clock is just the system clock (except it's
> explicitly
> >>> not supposed to adjust for system time[1]).  But just because you're
> using
> >>> DOMHRTS type doesn't explicitly mean you're using the system clock -
> >>> sections 4.3 and 4.4 are specific to the usage in
> window.performance.now(),
> >>> and the rest of the spec simply defines the type (= #1 above).
> >>
> >>
> >> For consistency, I'd go with the navigationStart, i.e.
> >> window.performance.now(), we should avoid respecifying things that other
> >> groups have already specified, such as clocks. As for audio/midi clock
> >> synchronization, I think it isn't anything that needs to be visible to
> the
> >> end developer, the implementations should just synchronize with these
> >> internally, imho.
> >>
> >>>
> >>> For the purposes of the MIDI API, I don't have any real problem with
> >>> using the DOMHRTS type - but I'm a) not really psyched about having to
> use
> >>> window.performance.now() in a MIDI application to get the
> zero-reference,
> >>> because it seems like that is really designed to be a
> performance-timing
> >>> thing, and b) a little less pleased that Web Audio times are in
> seconds, and
> >>> this timestamp would be in milliseconds.  Neither of those are
> completely
> >>> disastrous, but they both seem less than optimal.  Anyone else have
> thoughts
> >>> on that?  Any thoughts about how developers usually think?
> >>
> >>
> >> Personally I think it's a bit confusing that Web Audio API uses seconds
> >> instead of milliseconds, because like I said, most time related values
> on
> >> the web are presented as milliseconds.
> >>
> >> Cheers,
> >> Jussi
> >
> >
>