This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20411 - timestamp in MIDIEvent in odds with DOM4 Event timeStamp?
Summary: timestamp in MIDIEvent in odds with DOM4 Event timeStamp?
Status: CLOSED FIXED
Alias: None
Product: AudioWG
Classification: Unclassified
Component: MIDI API (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: TBD
Assignee: Chris Wilson
QA Contact: public-audio
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-17 14:26 UTC by Jussi Kalliokoski
Modified: 2013-01-18 15:51 UTC (History)
2 users (show)

See Also:


Attachments

Description Jussi Kalliokoski 2012-12-17 14:26:23 UTC
[ Marcos Caceres wrote ]

DOM4 Event defines:
readonly attribute DOMTimeStamp timeStamp;


While MIDIEvent [1] defines timestamp:
readonly attribute DOMHighResTimeStamp timestamp;

I think that is going to lead to confusion. Perhaps it might be worth talking to the WebIDL people and getting them to up the precision of DOMTimeStamp? Or easier to just rename the MIDIEvent attribute? Cameron, thoughts?
Comment 1 Jussi Kalliokoski 2012-12-17 14:30:38 UTC
(In reply to comment #0)
> [ Marcos Caceres wrote ]
> 
> DOM4 Event defines:
> readonly attribute DOMTimeStamp timeStamp;
> 
> 
> While MIDIEvent [1] defines timestamp:
> readonly attribute DOMHighResTimeStamp timestamp;
> 
> I think that is going to lead to confusion. Perhaps it might be worth
> talking to the WebIDL people and getting them to up the precision of
> DOMTimeStamp? Or easier to just rename the MIDIEvent attribute? Cameron,
> thoughts?

Hmm, I doubt upping the precision of DOMTimeStamp makes sense for the use cases it serves. I think it's a better idea to rename the timestamp to something less ambiguous, but my best (and worst) idea for now is "MIDITimeStamp" (I have no preference on the casing), but that's not very appealing.

But I agree, it's confusing to have "timestamp" and "timeStamp" that may differ in times and in precision.
Comment 2 Marcos Caceres 2012-12-17 15:53:05 UTC
I'm wondering if we can just override it.
Comment 3 Jussi Kalliokoski 2012-12-17 15:58:38 UTC
(In reply to comment #2)
> I'm wondering if we can just override it.

You mean not have the DOM "timeStamp" at all, and instead rename "timestamp" to "timeStamp"? Sounds good to me, if it's not against the rules or something. :D
Comment 4 Marcos Caceres 2012-12-17 16:08:15 UTC
Certainly not against the rules. What I'm wondering is if there can be a difference between the MIDI's timestamp and the Event's timestamp. 

However, the timeStamp generally refers to the time at which the corresponding event took place of the thing one is interested in (and not when the Event object was constructed). If that definition of timeStamp holds, then I don't see any problem with overriding timeStamp to have a high precision.
Comment 5 Jussi Kalliokoski 2012-12-17 16:17:20 UTC
(In reply to comment #4)
> Certainly not against the rules. What I'm wondering is if there can be a
> difference between the MIDI's timestamp and the Event's timestamp. 
> 
> However, the timeStamp generally refers to the time at which the
> corresponding event took place of the thing one is interested in (and not
> when the Event object was constructed). If that definition of timeStamp
> holds, then I don't see any problem with overriding timeStamp to have a high
> precision.

Yes, that definition holds. Good!
Comment 6 Chris Wilson 2012-12-17 19:21:36 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > Certainly not against the rules. What I'm wondering is if there can be a
> > difference between the MIDI's timestamp and the Event's timestamp. 
> > 
> > However, the timeStamp generally refers to the time at which the
> > corresponding event took place of the thing one is interested in (and not
> > when the Event object was constructed). If that definition of timeStamp
> > holds, then I don't see any problem with overriding timeStamp to have a high
> > precision.
> 
> Yes, that definition holds. Good!

Yes, that definitions holds, but is it really okay to redefine the timeStamp to a completely different type?  The timestamps we have now are DOMHighResTimeStamps, which are a double representing time since navigation start; DOMTimeStamps are unsigned long longs representing (integer) milliseconds since 00:00:00 UTC on 1 January 1970.

receivedTime?
Comment 7 Marcos Caceres 2012-12-17 19:55:27 UTC
receivedTime wfm. Both measures (relative and absolute) is kinda nice.
Comment 8 Chris Wilson 2012-12-17 20:03:59 UTC
(In reply to comment #7)
> receivedTime wfm. Both measures (relative and absolute) is kinda nice.

Hmm.  You mean filling out timeStamp (in DOMTimeStamp format) as well as receivedTime (as a DOMHighResTimeStamp)?  Sigh.  Yeah, I suppose.
Comment 9 Marcos Caceres 2012-12-17 20:07:27 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > receivedTime wfm. Both measures (relative and absolute) is kinda nice.
> 
> Hmm.  You mean filling out timeStamp (in DOMTimeStamp format) as well as
> receivedTime (as a DOMHighResTimeStamp)?  Sigh.  Yeah, I suppose.

Well, that kinda needs to happen regardless as it's part of the DOMEvent interface. I guess what we need to say in the spec is that it reflects the receivedTime to the nearest millisecond (rounded or floored?).
Comment 10 Chris Wilson 2012-12-17 20:22:13 UTC
(In reply to comment #9)
> Well, that kinda needs to happen regardless as it's part of the DOMEvent
> interface. I guess what we need to say in the spec is that it reflects the
> receivedTime to the nearest millisecond (rounded or floored?).

Well that's the annoying part - since it's a completely different timeframe, it's a long conversion.  At least it's not on another hardware clock, like audio.

I'd suggest floored, but I think it's mostly irrelevant - I'd rather advise against using timeStamp, due to precision.  I wish it weren't there.
Comment 11 Chris Wilson 2012-12-26 18:09:26 UTC
Resolved with https://github.com/WebAudio/web-midi-api/commit/23d1a3f64c003ff49077f1a7c6477f109f1d53b9.

Renamed to receivedTime, and explicit mention of the DOM4 Event timeStamp as lower precision.
Comment 12 Olivier Thereaux 2013-01-18 15:51:00 UTC
Batch-closing RESOLVED MIDI issues. Reminder: midi issues now tracked at https://github.com/WebAudio/web-midi-api/issues