This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
[ 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?
(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.
I'm wondering if we can just override it.
(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
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.
(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!
(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?
receivedTime wfm. Both measures (relative and absolute) is kinda nice.
(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.
(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?).
(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.
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.
Batch-closing RESOLVED MIDI issues. Reminder: midi issues now tracked at https://github.com/WebAudio/web-midi-api/issues