Improve conversions between ticks and seconds

[rdoursenaud]

Deprecates tick2second in favor of ticks2seconds and second2tick in favor of seconds2ticks.
Returns fractional time is seconds per #528
Removes erroneous references to absolute in docstrings and comments.

Fixes #526

[page200]

Thank you for the nice discussions and commits! :)

One comment: I'd favor renaming resolution to the units it is given in, such as ticks_per_quarternote.

[rdoursenaud]

The unit is a property that is not descriptive enough IMHO.

I find that resolution conveys the intention better and I intend to use the same field name when revamping the MIDIFile class.

I pondered using time_ticks, time_seconds, resolution_tpqn and tempo_uspqn but I think it makes the API overly verbose and may confuse users more because of the lack of context provided by the documentation.

[rdoursenaud]

And thanks for the review!

[page200]

In what way do you consider ticks_per_quarternote not descriptive enough, I mean, what variables except for resolution can be given in ticks per quarternotes? If there are such variables, let's call this one resolution_in_ticks_per_quarternote or so. I suspect that ticks_per_quarternote is a good choice. Informative names are good.

Leaving out units would be a huge pain, especially in the context of MIDI, where time is so complicated already due to ticks vs. seconds vs. quarternotes and the various events that affect how to convert between those "units". "Resolution" might be given in ticks per quarternote, or ticks per second, or ticks per millisecond, or ticks per minute, or ticks per bar. Or maybe other things can also be considered "resolution", for example something related to the limited numerical precision of the inexact number of seconds that users might assume or recall from before the fix of #528, or the limited numerical precision of data in MIDI events such as tempo changes, or an assumption that mido voluntarily chooses to limit the resolution to some value by rounding. All these units, conversions, MIDI events (including how they affect conversions over time and how they have limited precision) and optional roundings are dauting, and ticks_per_quarternote nails it, it seems.

[rdoursenaud]

ticks_per_quarternote is just a unit it doesn't convey its purpose.
I just checked the SMF specification and they call this division, maybe we should use this to avoid bikeshedding as it is the trusted source.

[rdoursenaud]

Also the division field will need to have an intrinsic unit anyway since it can either be expressed in ticks per quarter note or ticks per frame.
We don't have support for the latter at the moment. See #457.