Correct timestamps when messages are ignored

[Boddlnagg]

Currently (at least on some platforms) relative timestamps are computed between messages, even when some messages are ignored and not forwarded to the user. For example:

• Message 1 is received by the user with timestamp 0
• Message 2 is ignored by the user
• Message 3 is received by the user, but contains a timestamp relative to message 2. There is no way for the user to know the real time that passed between the messages that the user actually received.

This could be fixed by either updating the "previous" timestamp only if the message is actually delivered to the user (and not ignored), or by switching to absolute timestamps altogether.

Currently I tend towards absolute timestamps (counting from some unspecified time in the past), because that's what the platforms provide, and it's also what WebMIDI uses.

Is there any strong argument for keeping relative timestamps? It seems to me that going from absolute to relative is something the user can do if it's needed, but going from relative to absolute (even if the bug described here is fixed) always involves some inaccuracies due to rounding, etc.

[Boddlnagg]

We could also return absolute timestamps as std::time::Duration, if the backends' timestamps can be converted easily.

[Boddlnagg]

Actually I think I'd prefer absolute timestamps. You can always go from absolute to relative, but the other way around inevitably introduces rounding errors ...

[Boddlnagg]

For reference: I checked what kind of timestamps the platforms actually give us, this is:

• Windows (MM): timestamp in milliseconds as u32 (https://msdn.microsoft.com/de-de/library/windows/desktop/dd757284(v=vs.85).aspx)
• ALSA: seconds as u32 + nanoseconds as u32 (http://alsa-project.org/alsa-doc/alsa-lib/structsnd__seq__real__time.html)
• Jack: microseconds as u64 (http://jackaudio.org/files/docs/html/types_8h.html#af9a29b8728e95cc38e2932c0ef855b7e)
• MacOS: can obtain timestamp in nanoseconds (unclear resolution) as u64 ( using https://developer.apple.com/documentation/coreaudio/1422393-audioconverthosttimetonanos?language=objc)
• Windows (UWP): timestamp as TimeSpan structure, apparently as the "number of 100-nanosecond intervals", internally an i64 (https://docs.microsoft.com/en-us/uwp/api/windows.devices.midi.imidimessage and https://docs.microsoft.com/en-us/uwp/api/windows.foundation.timespan)

Furthermore, PortMidi uses timestamps in milliseconds as u32 (see https://github.com/xlab/portmidi/blob/a2cf51204affa3600b0e6e15c7174cd5cbde463b/pm/portmidi.h#L265-L269)

From these considerations, I think that providing timestamps in microseconds as u64 (as an absolute time span from an undefined starting point) is reasonable as an abstraction over these different formats. Comments?