As noted in the essay on musical timing, computers can measure absolute time with great precision, to the nearest millisecond or microsecond, but for musical purposes it’s generally more suitable to use “tempo-relative” time, in which we refer to units of time as measures, beats, and ticks (fractions of a beat) relative to a given tempo stated in beats per minute (bpm). (For the purpose of this discussion, we’ll consider “beat” and “quarter note” to be synonymous.)

The default—and most common—unit of time in Max is the millisecond. Almost all timing objects (cpuclock, metro, clocker, timer, delay, pipe, etc.) refer to time in terms of milliseconds by default. However, in Max (as in most DAW software) there exists a syntax for referring to time in a variety of formats: absolute time in milliseconds, absolute time in clock format (hours:minutes:seconds:milliseconds), audio samples (dependent on the audio sampling rate in effect), hours:minutes:seconds:frames (dependent on an established film/video frame rate), and tempo-relative time based on the tempo attribute stored in the transport.

Tempo-relative time, as controlled by the transport in Max, can be expressed in bars.beats.units (bbu format, equivalent to measures.beats.ticks in DAW software), note values, or simply in ticks. The relationship of those units to absolute time depends on the value stored in the transport‘s tempo attribute, expressed in bpm. A complete explanation of the time value syntax in Max is in the Max documentation. A complete listing of the objects that support time value syntax is also available in the documentation. (Just about all time-related objects do support it.) To translate automatically from one format to another, the translate object is useful. (The translate object works even when the transport is not running.)

When the transport is on, its sense of time moves forward from the specified starting point, and it governs all timing objects that refer to it. If a timing object is using absolute millisecond time units, it will be oblivious to the transport. However, if you specify its timing in tempo-relative units, it will depend on (and be governed by) the transport. The transport can be turned on and off in Max, its current time can be changed, its tempo and time signature can be changed, and it can be queried for information about the current tempo, the time signature, and the current moment in (its own sense of) time.

The phasor~ object can also be synchronized to a transport. Since the phasor~ can be used to drive many other MSP objects, many audio processes (such as oscillator rates, looping, etc.) can be successfully governed by the transport for tempo-relative musical timing.

In addition to the Max documentation cited above, you can read more about tempo-relative timing in Max in the article “Tempo-relative timing” and you can try out the example Max patch it contains. To understand the Max transport object and its implications for rhythmic timing, you can study this example of “Tempo-relative timing with the transport object“, read the accompanying explanatory text, and also study the other examples to which links are provided in that text.