Handling Time

The Two Major Problems

Any solution to representing time must be able to solve the following two problems with appropriate precision and efficiency:

Converting between time domains

Converting between audio and musical time domains is imprecise. If this only happens in one direction, then the nature of the imprecision is well-understood and can be controlled for.

Consider a given musical time Tm. Given the current (and for the purposes of this example, fixed) state of the tempo map, this maps to an audio domain time of Ta. The units of Ta are in samples, either integer, rational or floating point. If Tm corresponds to a position precisely halfway between two samples, then the nature of the representation of Ta is important. If integral, we must round the position up or down toward the nearest integral Ta. If rational or floating point, we are still effectively quantizing the representation of Ta in various ways.

This is not an issue if we only ever convert in one direction. For example, we might decide to use integral samples for audio time, and always round fractional values down, up or to the nearest integer. However, the moment we ever try to convert this value back to Tm, we will get the wrong answer.

The canonical example where this matters is when Tm would normally lie close to the boundary of a process cycle (beginning or end). The boundary is defined in audio time. One one cycle, we decide that Tm should be considered to be in the following cycle. On the next cycle, we decide that it should be in the previous cycle. The result is that we effectively never handle events at Tm.

As mentioned above, this will not happen if we only ever convert in a single direction (e.g. musical -> audio or audio->music) since the rounding will be consistent. But limiting the conversions to be only ever in a single direction in a DAW is hard. We may wish to add values from two different time domains and get the result in either time domain, for example.

Consequently, any time representation must be able to minimize (or preferably eliminate) any real-world penalties that might occur from bidirectional conversions between time domains.

Dealing with changes to the tempo map

Whatever form musical time is represented with, there will be times when the tempo map is changed. When this happens, potentially each and every musical domain time maps to a different audio domain time. This must be handled efficiently and completely.

If musical time is lazily converted to audio time (i.e. there is a canonical form that is recognizable as the musical time domain, and it remains available at all times), then we can simply recompute the mapping between Tm and Ta when necessary.

However, if musical time is converted into some other representation (audio time domain is the most obvious), then when the tempo map changes there is no way to recover the canonical position (see the section above on bi-directional conversion errors).

In addition, if there is a "time type" that does not convey the time domain it is using, there is no way to identify those values that may need updating after a tempo map change, and those that do not.