To detect when an audio event (such as a musical note) occurs, one straightforward method is to test whether the peak amplitude of the audio signal surpasses an established threshold that's slightly above the level of the ambient noise floor. The peakamp~ object periodically reports the greatest absolute value of amplitude that has occurred during the specified time interval. For quick response, that interval should usually be every 10 to 30 milliseconds.
Here is a workaround for instantly changing the time interval of a qlim object without waiting for the current cycle to end.
The examples above show two different ways that you can trigger sound files while keeping in sync with a particular beat when the durations of the sound files are not perfect multiples of the beat duration, hence triggering the next sound file at the ending point of the current sound file results in the next sound file being started off the beat.
If you want to synchronize realtime performed events to the Max transport, or to the Live transport in Max for Live, you need to hold onto the vital information about the performed event until the next beat (or downbeat, or whatever your unit of quantization is), then trigger it. For example, in Live, when you trigger a new audio clip, if the launch quantization is set to 1 Bar, your clip will not be launched until the next downbeat. Live holds onto your request to launch the clip, then enacts it when the downbeat of the next bar arrives.
A common way of detecting the onset of a significant event in a continuous stream of data is to look for the data to exceed a certain threshold. For example, detecting when the amplitude exceeds a certain level in an audio signal can indicate that a sonic event has occurred. One common problem with threshold detection is that data might fluctuate around the threshold, going above and below it many times, and thus giving a false reading of multiple triggering events.