Using delay for inactivity trigger

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.

Ducking when changing delay time using tapin~ and tapout~

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.

Bass drum player with swing

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.

Delay with feedback

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.

Simple flanging

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.

Ducking when changing delay time

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.

Delay with tempo-relative timing

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.