Re: [PD] Good Time Stretching patches/advice?

[Derek Kwan]

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
#N canvas 293 330 747 610 10;
#X obj 165 126 soundfiler;
#X obj 169 358 dac~ 1 2;
#X obj 177 62 openpanel;
#X obj 183 36 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 519 76 vsl 15 128 0.01 1 0 0 empty empty rate 0 -9 0 10 -262144
-1 -1 12700 1;
#X floatatom 508 217 5 0 0 0 - - -, f 5;
#X obj 183 326 *~ 0;
#X obj 189 228 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X obj 571 78 vsl 15 128 -12 12 0 0 empty empty transposition 0 -9
0 10 -262144 -1 -1 6350 1;
#X floatatom 560 217 5 0 0 0 - - -, f 5;
#X msg 569 40 0;
#X msg 512 36 1;
#X obj 533 13 loadbang;
#X obj 329 26 loadbang;
#X obj 83 227 table test1;
#N canvas 1 59 912 532 phreadabstract 0;
#X obj 336 28 inlet;
#X obj 467 28 inlet;
#X obj 336 50 t b f;
#X obj 242 126 samplerate~;
#X obj 296 187 /;
#X obj 293 297 phasor~;
#X obj 296 228 * 1;
#X obj 350 172 t b f;
#X obj 293 341 outlet~;
#X text 385 28 sample size;
#X text 508 27 rate;
#X text 34 17 PHASREAD~: sample indexer abstraction;
#X obj 577 31 inlet;
#X text 614 32 phase;
#X text 30 75 in1: sample size;
#X text 28 94 in2: rate;
#X text 29 114 in3: phase;
#X text 28 154 DEREK KWAN \, 2016;
#X text 36 35 using phasor~;
#X obj 293 319 *~ 1;
#X connect 0 0 2 0;
#X connect 1 0 7 0;
#X connect 2 0 3 0;
#X connect 2 1 4 1;
#X connect 2 1 19 1;
#X connect 3 0 4 0;
#X connect 4 0 6 0;
#X connect 5 0 19 0;
#X connect 6 0 5 0;
#X connect 7 0 6 0;
#X connect 7 1 6 1;
#X connect 12 0 5 1;
#X connect 19 0 8 0;
#X restore 205 190 pd phreadabstract;
#X obj 172 244 fgrainstr2~ test1 10;
#X obj 347 247 fgrainstr~ test1 10;
#X text 393 223 SOUND ON/OFF;
#X obj 325 309 *~ 0;
#X obj 377 225 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X text 214 225 SOUND ON/OFF;
#X msg 158 91 read -resize -maxsize 4e+06 \$1 test1;
#X obj 151 292 *~ 0.25;
#X obj 363 274 *~ 0.25;
#X text 48 26 Derek Kwan \, 2016;
#X text 47 42 fgrainstrtest;
#X connect 0 0 15 0;
#X connect 2 0 22 0;
#X connect 3 0 2 0;
#X connect 4 0 5 0;
#X connect 4 0 15 1;
#X connect 6 0 1 0;
#X connect 6 0 1 1;
#X connect 7 0 6 1;
#X connect 8 0 9 0;
#X connect 8 0 17 2;
#X connect 10 0 8 0;
#X connect 11 0 4 0;
#X connect 12 0 11 0;
#X connect 12 0 10 0;
#X connect 13 0 11 0;
#X connect 15 0 16 0;
#X connect 15 0 17 0;
#X connect 16 0 23 0;
#X connect 17 0 24 0;
#X connect 19 0 1 0;
#X connect 19 0 1 1;
#X connect 20 0 19 1;
#X connect 22 0 0 0;
#X connect 23 0 6 0;
#X connect 24 0 19 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Good Time Stretching patches/advice?

[Derek Kwan]

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

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Good Time Stretching patches/advice?

[Derek Kwan]

> 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

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Good Time Stretching patches/advice?

[Jaime Oliver]

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.  
> 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  > wrote:
> phase vocoders, try the example in the help patches. 
> best,
> J
>> On Apr 14, 2016, at 1:32 AM, S.E.P. > > 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-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 
>> 
> 
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Good Time Stretching patches/advice?

[S.E.P.]

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 
wrote:

> phase vocoders, try the example in the help patches.
> best,
> J
>
> On Apr 14, 2016, at 1:32 AM, S.E.P. <
> dreamoftheshoreofanotherwo...@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-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
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Good Time Stretching patches/advice?

[Jaime Oliver]

phase vocoders, try the example in the help patches. 
best,
J
> On Apr 14, 2016, at 1:32 AM, S.E.P.  
> 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-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

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Good Time Stretching patches/advice?

[michael noble]

On Thu, Apr 14, 2016 at 2:32 PM, S.E.P. <
dreamoftheshoreofanotherwo...@gmail.com> wrote:

> Any advice?


Perhaps Katja's Soundtouch external?
http://www.katjaas.nl/pitchshift/soundtouch~.html
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Good Time Stretching patches/advice?

[S.E.P.]

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