hi for some experiments with fast fourier transformation it would be nice to work with a bigger blocksize than 64 samples. but my pd computes audio only with a blocksize of 64samples (my pd runs under w98), even i try a blocksize smaller than 64 samples. from what are the allowed blocksizes dependent? what should be the biggest and the smallest possible blocksize? what means the second argument for the object [block~]?
thanks
Gesendet von http://mail.yahoo.de Jetzt buchen! Tolle Best Price Angebote bei Expedia.de, dem groÃen Online-Reisebüro.
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
for some experiments with fast fourier transformation it would be nice to work with a bigger blocksize than 64 samples. but my pd computes audio only with a blocksize of 64samples (my pd runs under w98), even i try a blocksize smaller than 64 samples.
How do you try this? You can set the blocksize with the [blocksize~] internal as low as 1 and quite big, too. The blocksize is valid for the whole subpatch. ciao
On Sun, 20 Jul 2003, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
for some experiments with fast fourier transformation it would be nice to work with a bigger blocksize than 64 samples. but my pd computes audio only with a blocksize of 64samples (my pd runs under w98), even i try a blocksize smaller than 64 samples.
How do you try this? You can set the blocksize with the [blocksize~] internal as low as 1 and quite big, too. The blocksize is valid for the whole subpatch.
... but be sure to set the blocksize within a subpatch. It won't work (yet) if you set it in the same patch where the dac~ and/or adc~ objects are.
Guenter
Roman Haefeli wrote:
biggest and the smallest possible blocksize? what means the second argument for the object [block~]?
overlap-factor the third argument would be the upsampling-factor (thus [block~ 64 1 0.5] would downsample the signal to 22.05kHz (if pd is running at 44.1kHz)
the [block~] arguments are valid for the whole subpatch (as others have noted). it is also valid, for all child-patches of the patch, this is: all nested subpatches and abstractions (unless overwritten with another [block~], of course)
mfg.as.dr IOhannes
thanks