I've used this sampler for a while when I want to stretch out a sample indefinitely. It works well with simple sounds like organ, but repetitive fluctuations in volume and color seem to be inevitable when using more complex sounds like contrabass:

sampleread~.pd sampler.pd

I've just tried out the "freeze" option of the [cpitchshift] patch posted here: http://forum.pdpatchrepo.info/topic/9373/freeze-patches. At the highest window (32768), it is more stable than the sampler, but has a very metallic, artificial sound, as if it's been run through some heavy reverb and had some static to it. Lower windows sound worse. Any ideas or other patches you could recommend?

@whale-av Thank you, David. Your model works very well indeed with the contrabass sample. However, I decided to test it with a more complex sound, i.e. a saxophone multiphonic, and seem to be facing some difficulty. Cutting out the smallest period (wn04a-held.wav) makes it unrecognizable. Cutting out four periods (wn04a-held2.wav) makes the spectrum more recognizable, but, of course, the spectral fluctuations that are characteristic for this sound aren't present. I tried cutting out a much larger section (wn04a-held3.wav) which resembles two "waves". It clicks when I play it in your sampler, but this might be because I cut it poorly (I tried using Reaper's "Split items at prior zero-crossing" command, but I'm not sure how reliable it is. I also tried doing it visually). I've attached the three files mentioned above as well as the original file(wn04a-held-full.wav).wn04a-held.wav wn04a-held2.wav wn04a-held3.wav wn04a-held-full.wav

Edit: Actually, the [small_paul1.pd] is really not bad for the sax-multiphonic. It does add somewhat of a metallic echo, but the change isn't as drastic as with the contrabass sound.

Of course, I'd prefer to find a solution that works with many different samples instead of having to find a unique solution for each instrument I want to sample...

@s.elliot.perez Hello s...... Could you zip them up..... the forum (or my browser) refuses to download as a .wav......... and then I will sleep on it. Obviously the best solution would be a patch that "cuts" "treats" "shapes" and "plays" "whatever" is "thrown" at it......
I will chew it over.....
David.

@whale-av saxmulti.zip

There you go, David. Thanks for your time.

hi there,

your conversation inspired me to make the this patch:
zerozero.pd

it will write any incoming sound to an array of a given size, then search for the first and the last zerocrossing and playback this section. so its basically wavestealing, freezing..
the size of the array to record to would be around 200-500 samps for 2 - 3 periods normal pitch sound at 44100 samplerate..
anyway, have fun!

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