Hi, I've been studying DSP theory, FFT-based techniques in particular. I've found the FFT tutorials in PureData to be a great place to see those techniques applied to sound.
However, one little implementation detail still has me confused: In the engine of the phase vocoder patch (the FFT-ANALYSIS subpatch), there is a Float object which is used to calculate the next read location in milliseconds. This value is then converted to a sample position & passed through a Line~ to specify the start location of the first Tabread4~.
What I don't understand is why the conversion of the Float from milliseconds to samples doesn't take into account the overlap of the subpatch-in other words, why isn't the local sample rate used, instead of the sample rate of the parent window?
Thanks in advance for any insight anyone might have to share.
Chris Campbell cb@inner-ear.net
Hi Chris,
I don't fully understand the semantics of sample rates in block~ed subpatches myself... anyway, I think in the case of overlap, sample rate isn't the number of samples per second, but rather, one over the time difference between successive samples, which then shouldn't change when you change overlap factor. It's a question of definition only, and really should ultimately be chosen for greatest convenience... but I don't yet think I know what ultimately will prove most convenient and I would hate to change it now...
cheers Miller
On Tue, May 21, 2002 at 09:59:40PM -0400, cb wrote:
Hi, I've been studying DSP theory, FFT-based techniques in particular. I've found the FFT tutorials in PureData to be a great place to see those techniques applied to sound.
However, one little implementation detail still has me confused: In the engine of the phase vocoder patch (the FFT-ANALYSIS subpatch), there is a Float object which is used to calculate the next read location in milliseconds. This value is then converted to a sample position & passed through a Line~ to specify the start location of the first Tabread4~.
What I don't understand is why the conversion of the Float from milliseconds to samples doesn't take into account the overlap of the subpatch-in other words, why isn't the local sample rate used, instead of the sample rate of the parent window?
Thanks in advance for any insight anyone might have to share.
Chris Campbell cb@inner-ear.net
hello list,
there was a request that went out to see granular synthesis patches that people have made...
so here's mine. (the patch to open is nm-grainer.pd) it's been a long time developing and is pretty much at a satifactory point for me, except for some limitations that mean i think i'll have to start writing an external for my next effort.... the main limitation is the 64 sample block size for control signals that prevents the sort of timing accuracy i'd like for sequencing grains.... thus this patch has some not-so-pure sounds, although still quite useable i think.
it uses zexy for mavg, but can run without it, and also uses an adaptation of nqpoly~.pd from pix.test.at - thanks!
have fun with the patch, and let me know if you have comments.
cheers Nick
Nick Mariette hat gesagt: // Nick Mariette wrote:
the main limitation is the 64 sample block size for control signals that prevents the sort of timing accuracy i'd like for sequencing grains.... thus this patch has some not-so-pure sounds, although still quite useable i think.
I couldn't check you patch yet, but to circumvent this problem the t3_* objects in IEMLIB were designed. ciao,
It isn't my work, but I recently "ported" nobuyasu sakonda's max patch "granular2.0" to pd- if you know the original, you'll note that i've omitted the "prism" mode, though yves' xy controller could probably provide the same functionality. so far i've only tried it on linux, but i can't think of a reason it shouldn't work with win too. i'm including some my own abstrations and a few 3rd party externals required to make the magic.
Bill
Nick Mariette wrote:
hello list,
there was a request that went out to see granular synthesis patches that people have made...
so here's mine. (the patch to open is nm-grainer.pd) it's been a long time developing and is pretty much at a satifactory point for me, except for some limitations that mean i think i'll have to start writing an external for my next effort.... the main limitation is the 64 sample block size for control signals that prevents the sort of timing accuracy i'd like for sequencing grains.... thus this patch has some not-so-pure sounds, although still quite useable i think.
it uses zexy for mavg, but can run without it, and also uses an adaptation of nqpoly~.pd from pix.test.at - thanks!
have fun with the patch, and let me know if you have comments.
cheers Nick
re:granular2.0
i just realized i included sakonda's original samples in my previous post, making my attachment a little over 300k. damn. with any luck, the list server with strip off my error- if so and you'd like to try the patch, email me off-list for a copy. if the attachment does come through, my sincere apologies to everyone who has to download my mess.
Bill
Nick Mariette wrote:
hello list,
there was a request that went out to see granular synthesis patches that people have made...
so here's mine. (the patch to open is nm-grainer.pd) it's been a long time developing and is pretty much at a satifactory point for me, except for some limitations that mean i think i'll have to start writing an external for my next effort.... the main limitation is the 64 sample block size for control signals that prevents the sort of timing accuracy i'd like for sequencing grains.... thus this patch has some not-so-pure sounds, although still quite useable i think.
it uses zexy for mavg, but can run without it, and also uses an adaptation of nqpoly~.pd from pix.test.at - thanks!
have fun with the patch, and let me know if you have comments.
cheers Nick
HI.
not granular in the same way but kind of granular nonetheless. I posted this a while ago.. but people might be interested still..
http://www.nullpointer.co.uk/-/pd.htm
a pulse grain generator with array/envelopes to control window size/cycle speed e.t.c.
Have a look and let me know what you think..
Tom
----- Original Message ----- From: "linus" linus@publicbeta.cx To: "Nick Mariette" nmariette@myrealbox.com Cc: pd-list@iem.kug.ac.at Sent: Wednesday, May 22, 2002 7:44 PM Subject: Re: [PD] granular synthesis patch
re:granular2.0
i just realized i included sakonda's original samples in my previous post, making my attachment a little over 300k. damn. with any luck, the list server with strip off my error- if so and you'd like to try the patch, email me off-list for a copy. if the attachment does come through, my sincere apologies to everyone who has to download my mess.
Bill
Nick Mariette wrote:
hello list,
there was a request that went out to see granular synthesis patches that people have made...
so here's mine. (the patch to open is nm-grainer.pd) it's been a long time developing and is pretty much at a satifactory
point
for me, except for some limitations that mean i think i'll have to start writing an external for my next effort.... the main limitation is the 64 sample block size for control signals that prevents the sort of timing accuracy i'd like for sequencing grains.... thus this patch has some not-so-pure sounds, although still quite
useable i
think.
it uses zexy for mavg, but can run without it, and also uses an adaptation of nqpoly~.pd from pix.test.at - thanks!
have fun with the patch, and let me know if you have comments.
cheers Nick
-
cb -
Frank Barknecht -
linus -
Miller Puckette -
Nick Mariette -
nullpointer