Hi List,
As I've discussed at the PD patch repo, I'm looking for an optimal Time Stretching patch: http://forum.pdpatchrepo.info/topic/9909/time-stretching-patches-any-recomme...
From the ideas and patches proposed there (I'll refer to the post # to
avoid attachments), I've found that a simple array based patch with a very short sample works well for some patches, e.g. a contrabass (cf. post 17), whereas [small_paul1] works better for something more complex, like a saxophone multiphonic (cf. post 8 and 18).
Obviously, I'd prefer a unified solution that works for a wide variety of samples. Any advice?
Best regards, S.E.
On Thu, Apr 14, 2016 at 2:32 PM, S.E.P. < dreamoftheshoreofanotherworld@gmail.com> wrote:
Any advice?
Perhaps Katja's Soundtouch external? http://www.katjaas.nl/pitchshift/soundtouch~.html
phase vocoders, try the example in the help patches. best, J
On Apr 14, 2016, at 1:32 AM, S.E.P. dreamoftheshoreofanotherworld@gmail.com wrote:
Hi List,
As I've discussed at the PD patch repo, I'm looking for an optimal Time Stretching patch: http://forum.pdpatchrepo.info/topic/9909/time-stretching-patches-any-recomme... http://forum.pdpatchrepo.info/topic/9909/time-stretching-patches-any-recommendations
From the ideas and patches proposed there (I'll refer to the post # to avoid attachments), I've found that a simple array based patch with a very short sample works well for some patches, e.g. a contrabass (cf. post 17), whereas [small_paul1] works better for something more complex, like a saxophone multiphonic (cf. post 8 and 18).
Obviously, I'd prefer a unified solution that works for a wide variety of samples. Any advice?
Best regards, S.E. _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hey, thanks for your replies.
@Jaime Oliver I've tried the phase vocoders. They works well, though the sound does become more artificial the lower the speed is, e.g. more metallic with a contrabass sound. I really need an infinite stretch though. If I go ahead and use [I07.phase.vocoder.pd], do I need to modify it so that it reverses its reading of the array once the end is reached, or so it cross-fades into a rewind, or is there a better solution?
@michaelnoble I've also tried using [soundtouch~] for time stretching as demonstrated in its help file, but slowing down the playback and transposing it up leads to a very grainy, uncharacteristic sound.
On Thu, Apr 14, 2016 at 10:55 PM, Jaime Oliver jaime.oliver2@gmail.com wrote:
phase vocoders, try the example in the help patches. best, J
On Apr 14, 2016, at 1:32 AM, S.E.P. < dreamoftheshoreofanotherworld@gmail.com> wrote:
Hi List,
As I've discussed at the PD patch repo, I'm looking for an optimal Time Stretching patch: http://forum.pdpatchrepo.info/topic/9909/time-stretching-patches-any-recomme...
From the ideas and patches proposed there (I'll refer to the post # to avoid attachments), I've found that a simple array based patch with a very short sample works well for some patches, e.g. a contrabass (cf. post 17), whereas [small_paul1] works better for something more complex, like a saxophone multiphonic (cf. post 8 and 18).
Obviously, I'd prefer a unified solution that works for a wide variety of samples. Any advice?
Best regards, S.E. _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
you can control the reading position, not just make automatic playback. Try different window sizes, with and without phase locking to see if you find something you are looking for. tHere are other phase vocoder algorithms out there, I think Alexandre porres made one for pd, maybe one of tom Erbe’s externals?
best,
J
On Apr 14, 2016, at 1:01 PM, S.E.P. dreamoftheshoreofanotherworld@gmail.com wrote:
Hey, thanks for your replies.
@Jaime Oliver I've tried the phase vocoders. They works well, though the sound does become more artificial the lower the speed is, e.g. more metallic with a contrabass sound. I really need an infinite stretch though. If I go ahead and use [I07.phase.vocoder.pd], do I need to modify it so that it reverses its reading of the array once the end is reached, or so it cross-fades into a rewind, or is there a better solution?
@michaelnoble I've also tried using [soundtouch~] for time stretching as demonstrated in its help file, but slowing down the playback and transposing it up leads to a very grainy, uncharacteristic sound.
On Thu, Apr 14, 2016 at 10:55 PM, Jaime Oliver <jaime.oliver2@gmail.com mailto:jaime.oliver2@gmail.com> wrote: phase vocoders, try the example in the help patches. best, J
On Apr 14, 2016, at 1:32 AM, S.E.P. <dreamoftheshoreofanotherworld@gmail.com mailto:dreamoftheshoreofanotherworld@gmail.com> wrote:
Hi List,
As I've discussed at the PD patch repo, I'm looking for an optimal Time Stretching patch: http://forum.pdpatchrepo.info/topic/9909/time-stretching-patches-any-recomme... http://forum.pdpatchrepo.info/topic/9909/time-stretching-patches-any-recommendations
From the ideas and patches proposed there (I'll refer to the post # to avoid attachments), I've found that a simple array based patch with a very short sample works well for some patches, e.g. a contrabass (cf. post 17), whereas [small_paul1] works better for something more complex, like a saxophone multiphonic (cf. post 8 and 18).
Obviously, I'd prefer a unified solution that works for a wide variety of samples. Any advice?
Best regards, S.E. _______________________________________________ Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
Obviously, I'd prefer a unified solution that works for a wide variety of samples. Any advice?
Hello SEP (and list),
Another route is the granular route.
I've got a bunch of abstractions that attempt to replicate SuperCollider's Warp1 UGen. Basically the idea is to have grains occur one after another in a more-or-less fixed rate (with some randomness thrown in so you don't get a pitch from the grains themselves) and choosing the duration of each grain so that they overlap each other (I can't remember what I chose, I think something like 32x overlap? I think the default rate in Warp1 is 8x but I never managed to get it sounding good with that low of an overlap). I think as well as time-stretching, you have the option of pitch shifting (at least in fgrainstr).
fgrainstr needs fgrain (which is a "grain voice") and tukeymaker (which defines the window shape of each grain) and uses tabread4 if I remember correctly.
fgrainstr2 needs fgrain2 and tukeymaker and uses tabplay to get around the issue of very large index numbers.
With these abstractions, you can go down to a playback rate of 0. I didn't really code these abstractions with other eyes in mind, but I think they're commented enough to be useful.
I've also started making these into externals but I'm not sure if they sound as good as the abstraction versions quite yet (still working out the kinks). Instead of a Tukey window, I opted in this case to use a standard cosine window.
Here's the link to the abstractions on my github: https://github.com/derekxkwan/pure-data-abstractions/tree/master/fgrain
Derek Kwan
===================== Derek Kwan www.derekxkwan.com
@Derek Kwan Many thanks for your reply and your patches. I confess that I have a poor understanding of arrays and the related object and tend to use objects/abstractions that take an audio/open panel input. With your patches, as with some others I've seen, I need to put "pos (samples)" into the inlet and I'm not sure what that means. Also, while the 1st argument is the name of the array to be read, I don't know what "catchname" means for the 2nd argument.
@Jaime Oliver Have you used the Tom Erbe patches yourself? I downloaded the pack at this student's website: http://www.cooperbaker.com/home/code/pd%20spectral%20toolkit/ . Oddly, Windows tells me there are redundant files and asks if I want to replace them when I unpack it in a clean folder. I also add the path in my preferences and am unable to access the .pd_darwin files...
Best regards, S E P
On Tue, Apr 19, 2016 at 2:58 PM, Derek Kwan derek.x.kwan@gmail.com wrote:
Obviously, I'd prefer a unified solution that works for a wide variety of samples. Any advice?
Hello SEP (and list),
Another route is the granular route.
I've got a bunch of abstractions that attempt to replicate SuperCollider's Warp1 UGen. Basically the idea is to have grains occur one after another in a more-or-less fixed rate (with some randomness thrown in so you don't get a pitch from the grains themselves) and choosing the duration of each grain so that they overlap each other (I can't remember what I chose, I think something like 32x overlap? I think the default rate in Warp1 is 8x but I never managed to get it sounding good with that low of an overlap). I think as well as time-stretching, you have the option of pitch shifting (at least in fgrainstr).
fgrainstr needs fgrain (which is a "grain voice") and tukeymaker (which defines the window shape of each grain) and uses tabread4 if I remember correctly.
fgrainstr2 needs fgrain2 and tukeymaker and uses tabplay to get around the issue of very large index numbers.
With these abstractions, you can go down to a playback rate of 0. I didn't really code these abstractions with other eyes in mind, but I think they're commented enough to be useful.
I've also started making these into externals but I'm not sure if they sound as good as the abstraction versions quite yet (still working out the kinks). Instead of a Tukey window, I opted in this case to use a standard cosine window.
Here's the link to the abstractions on my github: https://github.com/derekxkwan/pure-data-abstractions/tree/master/fgrain
Derek Kwan
===================== Derek Kwan www.derekxkwan.com
On Apr 20, S.E.P. wrote:
@Derek Kwan Many thanks for your reply and your patches. I confess that I have a poor understanding of arrays and the related object and tend to use objects/abstractions that take an audio/open panel input. With your patches, as with some others I've seen, I need to put "pos (samples)" into the inlet and I'm not sure what that means. Also, while the 1st argument is the name of the array to be read, I don't know what "catchname" means for the 2nd argument.
Hey,
Sorry, I should get around to documenting these abstractions a bit more. fgrainstr2 is a bit more well documented than fgrainstr and I'll get around to specifying things more clearly, which I will do right now...
THe first inlet in both are like tabread4~ in that you index into your soundfile (loaded by soundfiler) by sample. A normal sample rate Pure Data is run at is 44100 Hz (you can find this value by banging samplerate~) so to read through a soundfile at a normal rate, you'd index into the object (tabread4 or my fgrainstr) from 0 to 44100 over 1 second to play back the first second at a normal speed and from 0 to 22100 over 1 second to play through the first half second at half speed. You could do this indexing by using something like phasor~ or even easier, line~ by first sending the message 0 to line~ then the message "44100 1000" to ramp to 44100 over 1 second. The audio examples included with Pure Data (namely the ones at the beginning of B) and the help file for soundfiler explain how PD deals with soundfiles more clearly that I just did...
As for the specifics in dealing my abstractions, you only really need to deal with fgrainstr and fgrainstr2 (but make sure that fgrain/fgrain2/tukeymaker are in the same folder). You don't even need to open those other abstractions, they're just there to help the main abstractions fgrainstr and fgrainstr2 do their business.
Derek
===================== Derek Kwan www.derekxkwan.com
Hey Derek (and list)
Thanks for the clarification. I put together a test patch for your fgraintstr~ (tesuto.pd) and tested it with the attached .wav file (you need to click on the "read" message). It would seem it works without inputting any values into the left inlet, which is tantamount to a freeze, I assume...?
I'm not sure what a good grain rate is... maybe in the 20s or 30s. In general, it sounds a bit fuzzy and electronic and the harmonic spectrum is very unstable... but I'm probably doing something wrong. Any more tips?
Best, S E P
On Thu, Apr 21, 2016 at 4:14 AM, Derek Kwan derek.x.kwan@gmail.com wrote:
On Apr 20, S.E.P. wrote:
@Derek Kwan Many thanks for your reply and your patches. I confess that I have a poor understanding of arrays and the related object and tend to
use
objects/abstractions that take an audio/open panel input. With your patches, as with some others I've seen, I need to put "pos (samples)"
into
the inlet and I'm not sure what that means. Also, while the 1st argument
is
the name of the array to be read, I don't know what "catchname" means for the 2nd argument.
Hey,
Sorry, I should get around to documenting these abstractions a bit more. fgrainstr2 is a bit more well documented than fgrainstr and I'll get around to specifying things more clearly, which I will do right now...
THe first inlet in both are like tabread4~ in that you index into your soundfile (loaded by soundfiler) by sample. A normal sample rate Pure Data is run at is 44100 Hz (you can find this value by banging samplerate~) so to read through a soundfile at a normal rate, you'd index into the object (tabread4 or my fgrainstr) from 0 to 44100 over 1 second to play back the first second at a normal speed and from 0 to 22100 over 1 second to play through the first half second at half speed. You could do this indexing by using something like phasor~ or even easier, line~ by first sending the message 0 to line~ then the message "44100 1000" to ramp to 44100 over 1 second. The audio examples included with Pure Data (namely the ones at the beginning of B) and the help file for soundfiler explain how PD deals with soundfiles more clearly that I just did...
As for the specifics in dealing my abstractions, you only really need to deal with fgrainstr and fgrainstr2 (but make sure that fgrain/fgrain2/tukeymaker are in the same folder). You don't even need to open those other abstractions, they're just there to help the main abstractions fgrainstr and fgrainstr2 do their business.
Derek
===================== Derek Kwan www.derekxkwan.com
On Apr 21, S.E.P. wrote:
Hey Derek (and list)
Thanks for the clarification. I put together a test patch for your fgraintstr~ (tesuto.pd) and tested it with the attached .wav file (you need to click on the "read" message). It would seem it works without inputting any values into the left inlet, which is tantamount to a freeze, I assume...?
I'm not sure what a good grain rate is... maybe in the 20s or 30s. In general, it sounds a bit fuzzy and electronic and the harmonic spectrum is very unstable... but I'm probably doing something wrong. Any more tips?
Hey,
I've attached a patch for you to test out. It sounds fine with smaller soundfiles, but kinda gets unstable with larger soundfiles due to the heaviness of the abstraction...I wrote the abstraction originally for a piece that I ported from supercollider that live-stretches a kalimba to something like 100 times it's original length so I didn't have to use super long soundfiles. I also had the grainrate around 5 ms so that means grains at length 5*32 = 160 ms. Also I didn't do any normalization in these abstractions (but in my external version I do) so note in the test patch I've attached I multiply the outputs of the fgrainstr abstractions by 0.25. Note that fgrainstr2 doesn't do any transposition, but it deals better with longer sound files due to indexing and float precision.
If you know how to compile stuff, you can also check out my external version that's also on my github page in the dxkpure repository. That whole thing is sort of in a pre-release stage because I haven't figured out the build process quite yet and my main machine runs ubuntu so I can only provide externals built for linux so far... I've kind of moved my efforts from making abstractions to making externals in interests of efficiency...
Derek
===================== Derek Kwan www.derekxkwan.com
Hey Derek, list,
Many thanks for the abstraction, it made testing much easier. I find overall that your patches add a metallic reverb-like sound to the stretched sample (not sure why that is). Also, probably due to the randomized grains, there's a very irregular sound in the resulting stretch
- the harmonic spectrum of the contrabass sample (attached) fluctuates very
actively. The sax multiphonic sample (also attached) already has a fluctuating sound - but it's a rhythmic flux that, in the stretch resulting from your patches, becomes less regular. I wonder if there's a way to address this or if these aren't inherent issues with the granular method of time-stretching.
On another note, a user named "solipp" at the pdpatchrepo uploaded a good time-stretcher, though it does have two small issues I haven't figured out yet: http://forum.pdpatchrepo.info/topic/9909/time-stretching-patches-any-recomme...
Best, S E P
On Fri, Apr 22, 2016 at 11:11 AM, Derek Kwan derek.x.kwan@gmail.com wrote:
On Apr 21, S.E.P. wrote:
Hey Derek (and list)
Thanks for the clarification. I put together a test patch for your fgraintstr~ (tesuto.pd) and tested it with the attached .wav file (you
need
to click on the "read" message). It would seem it works without inputting any values into the left inlet, which is tantamount to a freeze, I assume...?
I'm not sure what a good grain rate is... maybe in the 20s or 30s. In general, it sounds a bit fuzzy and electronic and the harmonic spectrum
is
very unstable... but I'm probably doing something wrong. Any more tips?
Hey,
I've attached a patch for you to test out. It sounds fine with smaller soundfiles, but kinda gets unstable with larger soundfiles due to the heaviness of the abstraction...I wrote the abstraction originally for a piece that I ported from supercollider that live-stretches a kalimba to something like 100 times it's original length so I didn't have to use super long soundfiles. I also had the grainrate around 5 ms so that means grains at length 5*32 = 160 ms. Also I didn't do any normalization in these abstractions (but in my external version I do) so note in the test patch I've attached I multiply the outputs of the fgrainstr abstractions by 0.25. Note that fgrainstr2 doesn't do any transposition, but it deals better with longer sound files due to indexing and float precision.
If you know how to compile stuff, you can also check out my external version that's also on my github page in the dxkpure repository. That whole thing is sort of in a pre-release stage because I haven't figured out the build process quite yet and my main machine runs ubuntu so I can only provide externals built for linux so far... I've kind of moved my efforts from making abstractions to making externals in interests of efficiency...
Derek
===================== Derek Kwan www.derekxkwan.com
-
Derek Kwan -
Jaime Oliver -
michael noble -
S.E.P.