Long term crescendo
This patch uses tempo to control the timing of a long crescendo in musical terms.
This patch uses tempo to control the timing of a long crescendo in musical terms.
This patch shows a simple use of a transport-governed metronome to trigger events at a constant rate. The metro object that has the argument '4n' will be governed by the transport because its interval is specified in a tempo-relative, music-based "note values" format. (Just for the sake of comparison, the patch includes another metro that is unaffected by the transport because its interval is specified in milliseconds.) The transport-governed metro will only run when the transport is on.
This example shows how to convert a value expressing “notes per second” into "milliseconds per note", which is a more useful value for the metro object. The right side of the patch shows how to use the tempo object to specify tempo in bpm, and to specify the division of the whole note at which to output numbers indicating which division of the measure it's on.
In order for this patch to work properly, you'll need to first download the attached .zip archive of six short soundfiles, uncompress it, and put the sound files in the Max search path.
You'll also need to download the patch from the example Subpatch for paying sound cues from sflist~. Save it with the name "playsamples.maxpat" in the Max file search path.
To coordinate the tempo of the transport object with the length of a recorded audio loop, get the duration of the loop in milliseconds, divide it by the number of beats, and divide the result in 60,000 (ms per minute) to calculate the tempo of the transport in beats per minute.
This patch provides examples that compare linear rate changes to exponential rate changes. As with pitch and loudness, our sense of change in the rate of events is based on the ratio of tempos rather than the (subtractive) difference between tempos. In these examples, the rate changes by a factor of 16, from 1 event per second to 16 events per second, or vice versa.
The function object can be used to create line segment functions that control a line~ object, and it can also be used as a lookup table. A number coming in its inlet will be treated as a point on the x-axis, and whatever y-axis value is shown on the line segment function at that point will be sent out the leftmost outlet. This example patch demonstrates that use of function.
The delay attribute (the delay time) of a delay~ object can be specified with tempo-relative timing (such as ‘notevalues’) instead of samples. This example shows a delay time of a dotted eighth note rhythmic value, at whatever the current transport tempo is. The transport tempo is 120 bpm by default; a dotted eighth note at that tempo will last 375 ms which, at a sample rate of 44100 samples per second, is 16,537.5 samples.
A phasor~ object, like other MSP objects such as cycle~ that use a rate for their timing, can have its repetition rate specified as a transport-related tempo-relative time value (note values, ticks, etc.). So if you want a phasor~ to work at a rate that is related to the transport's tempo, you can type in a tempo-relative time as an argument to specify its period of repetition instead of typing in a frequency.