Hmm, radio buttons save their current state with the patch when the patch is saved, even when "no init" is selected. To make matters worse, the button's display does not reflect that state when it first loads. That leads to weird things like this:
radio buttons save state with patch.pd
All I did was load the patch and click on the upper bang.

(Win 10, Pd 0.51.4 64 bit)

For future students & fellow nerds, here’s what I was suggesting:

See? Opposite sign, contrary to the text.

RE sample rate, let s’ = s/R (in English: specify the window size in seconds instead of samples). Then:

which is what the example patch G09 is computing for the phasor frequency.

RE Hann windowing with 4x overlap, it definitely sounds worse in this case, still not sure why when it's better for the FFT.
time domain overlapped windowing.zip
I have a faint memory of an explanation in Miller's book why the positive part of the cosine function is a useful windowing function for time domain stuff, but I can't find it. Maybe I just saw it used a lot in the audio examples.

Hmm, it's interesting that these kinds of time-domain algorithms use cosine-shaped windows and 2X overlap, whereas FFT resynthesis algorithms use Hann windows and 4X overlap. I've fooled around a little with FFT resynthesis using the former, and the sound is just a little coarser, which is to say I was surprised it wasn't terrible. I wonder if for something like time-domain pitch shift Hann+4X overlap would sound better (i.e. have softer windowing artifact) and if so, why.

(This question occurs to me just as I'm preparing to have no free time for a week so that's why I'm not just trying it and posting my results with further questions)

@morpheu5 Is "sample-level processing" the same as [block~ 1]? If so I don't see how that would necessarily make anything smoother. I wonder if the comparison with [gen~] is really apples to apples. (I also wonder if you think s.elliot.perez's patch is also not smooth)

@morpheu5 I've only played with Karplus-Strong once, but I put a low pass filter in the feedback path, defaults to 4500 hz. Not sure if that's where yours was. I also put one on the output, but not so close to the fundamental.

Edit: ha ha, I found where I stole that idea from. He's also doing something with the pluck function.

I'm serious: solve the original transposition formula for f. Show your work

It's a bad idea to post after cocktail hour, but here goes:

Regarding sample rate R, go back to the original transposition formula

Note that R is in samples/second and s is in samples/window. But in the example patch, s is specified in seconds (after the multiplcation by 0.001). So that factors out the sample rate coming from the transposition factor because you'd have to multiply s in seconds by the sample rate to get s in samples.

But that doesn't explain the [* -1]. I think there's just an algebra mistake in the text. Go ahead and solve the original transposition formula for f and you'll see that the sign is flipped.

@ricky Having looked for 10 minutes I can't figure out how the formula for f relates to the computation in the sample patch, but just looking at the patch itself, the negative frequency (i.e. multiplication by -1) makes sense to me because you want ever decreasing delay amounts. [phasor~] is an increasing ramp with positive frequencies.

@ricky

So the output sample here would be at the origin diagonal at the bottom of the blue vertical line as you've drawn it?

yes

Would I be correct in saying that the variable delay line is pitching down at that intersection in the illustration you've modified?

yes

The vertical lines are confusing, but he's trying to show how each of the input samples is weighted in the window envelope. Compare with the dataflow diagram fig 7.21.

@ricky
n is the given output sample index. You go up from there to intersect the origin diagonal as well as the one dot. The dot is d(n) to the right of the diagonal. Therefore, you want to output the input sample at n-d(n)