[PD-dev] [ pure-data-Patches-1509427 ] resampling method for halfblocks
SourceForge.net
noreply at sourceforge.net
Tue Jun 20 20:35:05 CEST 2006
Patches item #1509427, was opened at 2006-06-20 12:30
Message generated for change (Comment added) made by matju
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1509427&group_id=55736
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: resampling method for halfblocks
Initial Comment:
this patch adds a new pair of up/downsampling methods,
called "block".
what it does:
downsampling: the 1st part of the original signal is
copied "as is" to the downsampled signal; the rest of
the incoming signal is discarded
upsampling: the original signal is copied to the 1st
part of the upsampled signal; the rest of the upsampled
signal is set to 0.f
what for:
an the output-signals of an fft are redundant since
they are (anti)symmetric; therefore it is a waste of
cpu-power to apply dsp-processing on both halfs of such
signals;
with this patch it is possible to do a "downsampled"
processing only on the relevant (1st) part of the
signal (~50% performance gain): after upsampling you
would have to recreate the entire signal manually (e.g.
mirror the block and add it to the non-mirrored part)
i also put some defines for the various resampling
methods into m_pd.h, so the code gets less "magic"
----------------------------------------------------------------------
Comment By: Mathieu Bouchard (matju)
Date: 2006-06-20 14:35
Message:
Logged In: YES
user_id=801174
to save on CPU and memory, a "doubly real" FFT is possible:
not only real inputs, but also real outputs. For a
N-dimensional vector (block size N), there are 2N outputs.
The way that it is normally reduced back to N, is to combine
them to produce cosine and sine coefficients. I wonder
whether that'd be a more appropriate way of dealing with the
problem than using varying block sizes? (Maybe it's not)
Also, what seems to be a clearly interesting use of the
"block" method is that if you do [fft~] before a
"block"-upsampling and a [ifft~] just after, then you've
just done trigonometric interpolation, that is,
interpolation that uses sinusoids (instead of cubics and
stuff). IMHO this is the best way to upsample a signal *if*
block boundaries are properly dealt with (using windowing).
However, I've never tried this.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1509427&group_id=55736
More information about the Pd-dev
mailing list