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.