• ### Can someone explain to me what's going on in Johannes Kriedler's looping patch?

Hi folks,

Some context: I am building my own "oneshot" drum sampler and realized I got clicks/pops in the audio if I triggered notes too quickly. I was looking online for solutions and came to part of Johannes Kriedler's tutorials. I think some kind of amplitude windowing is what I need so as to ensure that each sample starts and stops at "0" amplitude to avoid clicks (see my included patch and sample).

Anyways before shamelessly copy-and-pasting Kriedler's patch into my own, I want to understand exactly what's going on. Below is a picture of Kriedler's example with [[my comments in brackets]].

Pd file in case the picture isn't big enough: kriedler.pd

Can anyone explain to me what's going on here?

My patch for reference: pdforum.zip

• | Posts 3 | Views 3934
• Hi,

Here are my thoughts on the patch you posted:

• what is actually getting the total ms of the sample is the [timer], since it calculates the time between two bangs, one which is sent when recording is activated, the other when the recording stops
• [expr 1000/\$f1] actually gets a frequency which should be fed to [phasor~] in order for it to go from 0. to 1. in the correct time - that is, in the sample duration. You can think of it in this way: 1000/\$f1, where \$f1 is a variable in ms would be equal to 1/\$f1 where \$f1 is in seconds, whose unit would be 1/sec which is the same as Hz).
• this [line~] before the [phasor~] is there to avoid any sudden jump of frequency from 0Hz until the desired one for [phasor~] since Kreidler sends a frequency of 0Hz when he wants to stop that [phasor~]. To be frank, after deleting it I don't hear any difference at all, but it is nice to always ramp these signal values.
• the significance of that [*~ 22049] is that it's simply the length of the table crown. I think it is irrelevant that its length is almost 1/2 of the sample rate - I modified it to have only 500 points, then I redrawn the trapezium shape and modified that multiplication object into [*~ 500] and everything worked the same as before (you just lose some "resolution" since you have less points to deal with).
• that ramp where you write "Isn't this what the window is supposed to accomplish?" is there for the sole reason of smoothly muting and unmuting the playback while recording. As soon as you finish recording and playback starts, it has no affect in the final result. Once again, it's there just to avoid clicks, but concerning only the transition from recording to playback, not playback to playback within a loop

I hope some of this helps. Take care,
Gilberto

• Ahh ok. Thanks for breaking it all down for me!

| Posts 3 | Views 3934
Internal error.

Oops! Looks like something went wrong!