RealTime represents seconds, as opposed to ScoreTime, which are abstract
units. Everything eventually is transformed into RealTime to be
performed.

This type has switched from floating point to decimal and back again. The
problem is that floating point is not exact, but there are a few
operations that require events that have the same ScoreTime to be grouped
with each other once they reach RealTime. For instance, controls are
clipped to the note boundaries, and a note is required to have a pitch at
exactly its starting time. While the event that produces the pitch signal
may have the same ScoreTime as the note it belongs to, if imprecision has
caused it to drift a little by the time it gets to performance, the note
may wind up with no initial pitch, or pick up the pitch of the next note
as a pitch bend.

An example of how imprecision can accumulate is a block call with pitch
set in the caller. If the sub-block has a note at 0 this should line up
with the start of the block call in the super-block and hence with a pitch
at the same time. But the sub-block has its own warp which is
a composition of the its tempo and the super-block's tempo. In theory the
sub-block's warp should be shifted so its 0 starts at the calling point
in the super-block, but in practice this is a number of floating point
operations (addition, linear interpolation, ...) and the value may very
well be slightly different.

Unfortunately switching RealTime to a lower-precision decimal type has the
same problem because it introduces even more imprecision due to the
ScoreTime -> RealTime -> ScoreTime conversion (this happens during warp
composition, for instance, since shift and stretch are in ScoreTime).
And I think it's ultimately not quite right because rounding will still
produce incorrect results if the imprecise value falls at a rounding
boundary.

Eventually, for MIDI at least, everything is rounded down to milliseconds
so hopefully any imprecision can be accounted for by the operations that
care about it and eventually be removed from the final result.

Documentation

This must have negative values because it's used for signals, which are
used for the warp map, which is oriented with zero at the note start. If
a note wants to get the real time before it, it must look up a negative
RealTime.