Dave Mollen

Does anyone know how to make a binshift effect inside pfft~?

I know there is fbinshift~, but I would like to do more advanced binshifting.

I would like to be able for instance to, how do I say this, invert or scramble the bins, instead of only shift them.

Does anyone know how to make a binshift effect inside pfft~?
I know there is fbinshift~, but I would like to do more advanced binshifting.
I would like to be able for instance to, how do I say this, invert or scramble the bins, instead of only shift them.
Should be possible, right?


fft-binshift

The trick is that the bins are sent out of 

 from lowest to highest. If you want to process them in a different order (or your process requires you have access to all the bins at once) you will need to buffer one FFT frame and then use that data to generate output during the next FFT frame—see my recent post in this thread (

https://cycling74.com/forums/ot-convolution-clarification)

 for a discussion on this being the reason I prefer working with FFT in C these days.

Here is an example that does inversion of the spectrum for you to take a look at:

Stay tuned for some externals I have for doing the types of things you are talking about that will be ready for release sometime in April.

The trick is that the bins are sent out of fftin~ from lowest to highest. If you want to process them in a different order (or your process requires you have access to all the bins at once) you will need to buffer one FFT frame and then use that data to generate output during the next FFT frame—see my recent post in this thread (https://cycling74.com/forums/ot-convolution-clarification) for a discussion on this being the reason I prefer working with FFT in C these days.

This patch uses a pfft~ abstraction named rm.fft.flip~

Stay tuned for some externals I have for doing the types of things you are talking about that will be ready for release sometime in April.


You'll find a few enjoyable baubles in the PeRColate collection (see www.maxobjects.com).

The only part I don't understand is the scaling just before [index~].

I think I understand I need a delay of half the FFT size, because it has to analyze the audio below Nyquist first,

before I can reorder it. (maybe I'm wrong here already..)

But I don't understand the calculations after the [delay~].

Thanks Roth. It works pretty nice!
The only part I don't understand is the scaling just before [index~].

I think I understand I need a delay of half the FFT size, because it has to analyze the audio below Nyquist first,
before I can reorder it. (maybe I'm wrong here already..)
But I don't understand the calculations after the [delay~].
Can you please explain?

You are right. To do this kind of bin processing, we need to use a 

). This is because we are only dealing with the 

 bins per FFT frame; we will be writing new FFT data into one half of the 

 while reading the previous frame's data for processing and output in the current frame. You are correct that 

 to be used in the calculation to get the read pointer.

 contains sample values describing the order (from lowest to highest) of the bins to be used for output (these values are between 

 reads this positions to get the output order (in this example, you could substitue 

 with calculations to flip the phasor output from 

 is useful to see how you could get other ordering. To get the appropriate samples indexes to read from 

 to index the half of the buffer that is not currently being written to. We do this with the calculations after the 

 abstraction the typed in arguments are for 

 in a while, but looking at this patch I'm wondering if the arguments to 

. I never had a problems with the way this patch is, but maybe I changed it in versions I actually used in performance. Let me think about that and get back to you.

I think I understand I need a delay of half the FFT size, because it has to analyze the audio below Nyquist first,
before I can reorder it. (maybe I'm wrong here already..)

You are right. To do this kind of bin processing, we need to use a buffer~ that has the size of the FFT size (n). This is because we are only dealing with the n/2 bins per FFT frame; we will be writing new FFT data into one half of the buffer~ #1-workspace while reading the previous frame's data for processing and output in the current frame. You are correct that count~ is used as the write index and delayed n/2 to be used in the calculation to get the read pointer.

buffer~ #1-flip contains sample values describing the order (from lowest to highest) of the bins to be used for output (these values are between 0 and n/2-1). The index from fftin~ reads this positions to get the output order (in this example, you could substitue index~ #1-flip with calculations to flip the phasor output from fftin~, but this example using index~ is useful to see how you could get other ordering. To get the appropriate samples indexes to read from  buffer~ #1-flip, we need to add 0 or n/2 to index the half of the buffer that is not currently being written to. We do this with the calculations after the delay~. 

If we divide the output of count~ by 2, we get a ramp from 0 to n/2, so that while count is writing to the first half of the buffer the delayed version is ramping from n/4 to n/2-1 and when count~ is writing to the second half of the buffer the delayed version is ramping from 0 to n/4-1.

Then by rounding to the nearest increment of n/2, we get a value that is n/2 when count~ is writing to the first half of the buffer and 0 when count~ is writing to the second half of the buffer.

By adding this with the output of index~ #1-flip the bin indices in buffer~ #1-flip will be scaled to index into the correct half of buffer~ #1-workspace.

In the pfft~ abstraction the typed in arguments are for n = 4096.

I haven't used this patch or pfft~ in a while, but looking at this patch I'm wondering if the arguments to count~ should be 0 4095 1 1. I never had a problems with the way this patch is, but maybe I changed it in versions I actually used in performance. Let me think about that and get back to you.


I'm interested in your externals coming out later by the way.

I would like to do some more of this FFT stuff.

Thanks for the explanation.
I totally understand now. Great..

I'm interested in your externals coming out later by the way.
I would like to do some more of this FFT stuff.


I'm double posting because I only came across this thread today, having already opened a new topic last night: 

https://cycling74.com/forums/adding-to-buffer-index-like-poke-but-not-overwriting/?reply_id=296925

I get the idea here but there is still one problem that I can't solve: how to accumulate the amplitude values of two or more bins into one index point to be read at the output? This implies some sort of feedback loop, which is a problem. Or does it!?

I'm double posting because I only came across this thread today, having already opened a new topic last night: https://cycling74.com/forums/adding-to-buffer-index-like-poke-but-not-overwriting/?reply_id=296925  

^oops, i shoulda found this one first as the thread is more relevant. oh well, good to cross-reference! :D

see that other thread for a solution to what you're describing:

https://cycling74.com/forums/adding-to-buffer-index-like-poke-but-not-overwriting/

(is it too obvious that i'm really happy with it? >:D)

^oops, i shoulda found this one first as the thread is more relevant. oh well, good to cross-reference! :D
see that other thread for a solution to what you're describing:
https://cycling74.com/forums/adding-to-buffer-index-like-poke-but-not-overwriting/

(is it too obvious that i'm really happy with it? >:D)


FFT binshift