@solipp Hey, thanks for your reply. I made the sample size 1500 and your patch works great with the contrabass sample! On the other hand, I'm not sure how to use it with a sax multiphonic (e.g. "wn04a-held"). As mentioned above, the latter requires much more time to become identifiable. 1500 is too short, many higher numbers produce odd skips, but, to my surprise, I found that 4081 (or thereabouts) produces a very stable and identifiable time stretch. The only problem is, I found this through trial and error and would have to do so for every sample I use in the future (and feed the sample length into the patch). I wonder if there's a way to automatize this process...zerozero.zip

@solipp Also, I find that, when I click on "find zerocrossings and play back" for the contrabass track (1500 sample window), the frequency is variable and can be different every time I click that button. Not sure why this is, but it's obviously an important issue. If we can clear this up, I might end up using the patch because, aside from the inconvenience of inputting the sample size, it's one of the most consistent stretching patches I've found yet (at least when testing with those two samples).

While experimenting with @solipp 's patch, I've found that, if I use a Trigger to bang the [open(, "sample size" and "find zero-crossings" in that order, the output is always the same for a given sample. With the contrabass sample, the result is excellent and the pitch is... almost the same; I hear a very slight difference. I tried this with a different contrabass sample and it worked - but with a different window size.

With the Trigger-method, the above named 4081 window size (post 24) does NOT produce a clean stretch. The cleanest I've found is 8119, with which the clicking sound is negligable and quickly ignored by the brain. So there are three variables here, it would seem: 1) the sample file 2) the array length 3) when the "find zero crossings..." inlet is banged. If I understand this correctly, the [readsf~] is looping continuously into the [tabwrite~] and banging it at different times starts writing the array at a different point in the .wav file. This variable complicates things, but you can bypass its variability by using the Trigger...

zerozero_test2.zip

Also, it seems a highly-irregular noise-like sample, e.g. metal rubbing against metal, can't be stretched with this patch, which makes sense. I might have to bite the bullet and use two different types of time stretch - something like @solipp 's patch for more regular, stable sounds, and perhaps the Miller Pucket vocoder to run through a longer sample window and "bounce" back and forth.