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.

In a standard MIDI file, there’s information in the file header about “ticks per quarter note”, a.k.a. “parts per quarter” (or “PPQ”). For the purpose of this discussion, we’ll consider “beat” and “quarter note” to be synonymous, so you can think of a “tick” as a fraction of a beat. The PPQ is stated in the last word of information (the last two bytes) of the header chunk that appears at the beginning of the file. The PPQ could be a low number such as 24 or 96, which is often sufficient resolution for simple music, or it could be a larger number such as 480 for higher resolution, or even something like 500 or 1000 if one prefers to refer to time in milliseconds.

What the PPQ means in terms of absolute time depends on the designated tempo. By default, the time signature is 4/4 and the tempo is 120 beats per minute. That can be changed, however, by a “meta event” that specifies a different tempo. (You can read about the Set Tempo meta event message in the file format description document.) The tempo is expressed as a 24-bit number that designates microseconds per quarter-note. That’s kind of upside-down from the way we normally express tempo, but it has some advantages. So, for example, a tempo of 100 bpm would be 600000 microseconds per quarter note, so the MIDI meta event for expressing that would be FF 51 03 09 27 C0 (the last three bytes are the Hex for 600000). The meta event would be preceded by a delta time, just like any other MIDI message in the file, so a change of tempo can occur anywhere in the music.

Delta times are always expressed as a variable-length quantity, the format of which is explained in the document. For example, if the PPQ is 480 (standard in most MIDI sequencing software), a delta time of a dotted quarter note (720 ticks) would be expressed by the two bytes 85 50 (hexadecimal).

So, bearing all that in mind, there is a correspondence between delta times expressed in terms of ticks and note values as we think of them in human terms. The relationship depends on the PPQ specified in the header chunk. For example, if the PPQ is 96 (hex 60), then a note middle C on MIDI channel 10 with a velocity of 127 lasting a dotted quarter note (1.5 beats) would be expressed as
00 99 3C 7F // delta time 0 ticks, 153 60 127
90 99 3C 00 // delta time 144 ticks, 153 60 0

Sound and music take place over time. Sonic phenomena change constantly over time, and therefore almost any consideration of them has to take time into account.

The word “rhythm” is used to refer to (sonic) events that serve to articulate, and thus make us aware of, how time passes. We become aware of intervals of time by measuring and comparing—either intuitively or with a time-measuring device such as a clock—the interval between events. We can detect patterns among those intervals, and we can recognize those patterns when they recur, even if with variations.

In everyday consideration of time, we discuss durations or intervals of time in terms of “absolute”, measurable clock time units such as hours, minutes, and seconds. When considering sound, we often need to consider even smaller units such as milliseconds (to accurately represent the rhythmic effect of events) or even microseconds (in discussions of audio sampling rate and the subsample accuracy needed for many digital audio signal processing operations).

Almost all programming languages provide a means of getting some numerical representation of the current time with millisecond or microsecond accuracy, such as the System.nanoTIme() method in Java, the cpuclock object in Max, etc. By comparing one instant to another, you can measure time intervals or durations with great accuracy.

When considering music, we most commonly don’t use direct reference to clock time units. Instead we refer to a “beat” as the basic unit of time, and we establish a metronomic “tempo” that refers indirectly to clock time in terms of beats per minute (bpm). Thus, a tempo of 120 bpm means that 120 beats transpire in one minute, so the beat interval (that is, the time interval between beats) is 60 seconds/minute divided by 120 beats/minute, which is 0.5 seconds/beat. Humans don’t consciously do that mathematical calculation; we just use the designated tempo to establish a beat rate, and then we think of the music in terms of divisions or multiples of the beat.

In the music programming language Csound, time is expressed in terms of beats, and the default tempo is 60 bpm, so time is by default also expressed in seconds. A command to change the tempo changes the absolute timing of all subsequent events, while keeping the same rhythmic relationships, relative to the designated tempo. Referring to units of time in terms of tempo, beats, measures (groups of beats), and divisions (fractions of beats) can be called “tempo-relative” time, to distinguish it from “absolute” time. This represents two different ways of talking about the same time phenomena; each has its usefulness. In most music, it makes more sense to use tempo-relative time, since we’re quite used to conceptualizing and recognizing musical timing in tempo-relative terms, yet not so good at measuring time in absolute terms (without the aid of a timekeeping device).

Most audio/MIDI sequencing programs, such as Live, Reason, Logic, Pro Tools, Cubase, Garage Band, etc. are based on the idea of placing events on a timeline, and they allow the user to refer to time either in terms of absolute time or tempo-relative time. For music that has a beat, tempo-relative time is usually preferable and more common. The norm is to have a way of setting the metronomic tempo in bpm, a way of setting the time signature, and then referring to points in time in terms of measures, beats, and ticks (fractions of a beat) relative to a starting point such as “1.1.0”, meaning measure 1, beat 1, 0 ticks. In most sequencing programs “ticks” means fractions of a quarter note, also sometimes called “parts per quarter”, regardless of the time signature. (That is, “ticks” always refers to fractions of a quarter note, even if we think of the “beat” as a half note as in 2/2 time, or an eighth note as in 5/8 time, or a dotted eighth note as in 6/8 time.) 480 ticks per quarter note is standard in most programs, the default time signature is 4/4, and the default tempo is 120 bpm. 480 ticks per quarter note gives timing resolution at nearly the millisecond level at that tempo. In Max, the measures.beats.ticks terminology is called bars.beats.units, but the idea is the same.