[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