@solipp Hey, thanks for your reply and your patch. I'm getting skipping sounds from a 5 second contrabass sound... maybe it's that the sample amount I estimated is wrong. Could someone remind me how to get the sample length in PD? I tried putting the filename via the [openpanel] into [symbol] into [read $1( into [soundfiler], but it seems I need to read it from an array, so I'd need to write it to an array first... maybe there's a simpler way?

@s.elliot.perez hey, sorry for late response.. [soundfiler] will output the size of the array to be filled, you can feed it with
[read -resize $1 arrayname( to get the sample length of your soundfile. If you are using extended you might want to check out [soundfile_info] too.
As for skipping sounds i'm not sure.. you should try a sample-length of about 1500 and feed your contrabass sound via readsf~ into the subpatch.

Edit: i migth have confused you with the comments in the patch.
"size of the recording" doesn't mean the actual size of a soundfile. it defines the size of a short record the patch will make.. like a photograph of some periods waveform of the incoming sound, then a phasor will play back this record from the first to the last zero-crossing.

@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.