What's the best way to detect lack of activity?
Let's say you want to Max to notify you if it has received no input for ten seconds. You could use a metro or a clocker to monitor activity constantly, and use a >= object to check when a time period 10,000 ms has been reached. However, by doing that, you're going to do lots of tests, only the last of which will give the looked-for result. There's an easier way.
This patch shows how you might combine several of the abstractions that are presented in other examples. The two key abstractions here are tapoutxfade~ and quadpan~. Those are not actual Max objects; they're both patches that have been saved with those names.
The main ways to delay a sound in Max are demonstrated in the examples from this site Simple delay of an audio signal and Delay with tempo-relative timing. You might want to take a look at those examples and read the associated text to review how they work, and what their pros and cons are.
One possible solution to the problem of clicks occurring when delay time is changed is to fade the amplitude of the delayed sound to 0 just before changing the delay time, then fade back up immediately after the change. This does avoid clicks, but causes an audible momentary break or dip in the sound. This shows one way you could implement such momentary "ducking" of the amplitude.
This patch shows several techniques relevant to granular synthesis, playing a stream of short excerpts of recorded sound. (The patch uses one abstraction, called pan~, that's provided in the example titled "Constant-intensity panning subpatch". You'll need to download that abstraction and save it with the name pan~ somewhere in Max's file search path.)
This patch uses the transport object to control an algorithmic performer of kick drum patterns. When the transport is turned on, the metro also turns on because its active attribute is set on. The metro sends a bang on every 16th note. Those bangs are first used to trigger information from the transport itself, and then to look up in a table of patterns to see whether or not to play a bass drum note.
The delay~ object does not permit its delayed signal to be fed back into its own left inlet. (You can probably imagine how that would make it impossible for MSP to calculate the correct signal, since you'd be asking it to perform infinite recursion: the signal plus the delayed signal plus the delayed sum of those two plus...). If you want to get delay with feedback, you need to use objects that are designed to handle that.
This patch demonstrates a simple implementation of "flanging"—the effect created by making a delayed copy of a sound, with the delay time periodically fluctuating, and then mixing the delayed sound with the original.
Whenever you change the delay time, you're asking MSP to look at a new location in the delay buffer, which can cause a click in the output if the new sample value is very different from the previous one. One way to get around that is to quickly fade the output amplitude down to 0 whenever you make a change, then quickly fade it back up once the change has been made.
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.