Is FFT size dependent of IO vector size?
Hello all,
I'm trying to learn Max and FFT and have a fundamental question. As I understand, if I perform a real-time FFT and choose a size of e.g. 512 samples, it takes 512 samples to convert the continuous values into spectral data.
Does this mean, that the FFT size can't be greater than the IO vector size (and/or signal vector size)?
Let's say I have a case where my IO size is 1024 and the FFT size is 512 samples. Since the IO vector determines the size of the "packages" Max uses to communicate with the hardware, I imagine that audio is sent to the dac although the FFT is only halfway done. What happens in such a case?
Or am I misunderstanding something and the FFT size is completely independent of IO size (and signal vector size)?
This'll be from memory, but here goes. It may be that your posting isn't confusing I/O vector size with Max's signal vector size, but just in case, I've added the paragraph immediately below....
The I/O vector refers to your sound card/interface, and it needs to be at least as large as Max's internal signal vector size.
Max's own internal signal vector doesn't really have much of a direct relation to FFT size (apart from CPU load, obviously). Generally, signal vector size is going to be part of a tradeoff of efficiency with latency.
I'm sure that one or our Max FFT Solons out there (Hey, Jean-François! Really looking forward to that new album with Ramin Roshandel. It's out on Bandcamp next month, right?) can probably hold forth on this from something other than memory, but I used to keep an eye on my CPU when I set Max's signal vector size (staying under 50-66% or so), setting it as low as I can or twice the I/O vector size - whichever one is bigger, depending on the interface.
I'm sure I'll be set straight if there are any howlers here. :-)
i´d say nothing in max depends on the IO vectorsize (except CPU hunger in some situations)
if anything, then the vectorsizte of the signal network can haven an effect on externals and subpatchers - but only regarding "minimum size" situations, the maximum is not relevant.
for example you can not make a feedbackloop with less than a vector delay, but you can make delays which are 3 hours long.
if anything, then the vectorsizte of the signal network can haven an effect on externals and subpatchers - but only regarding "minimum size" situations, the maximum is not relevant.
I see. So if I understand correctly: When I specify a fftsize of e.g. 1024 for my pfft~ object, it "overwrites" the global signal vector size (e.g. 512) for all objects inside the pfft~? And this would ensure that a whole fft-frame fits into one signal vector?
Note:
The manual for the frameaccum~/framedelta~ object says that " When used inside a pfft~ object, it keeps a running phase deviation of the FFT because the FFT size is equal to the signal vector size."
very thin ice for me, but let me try.
1. between fftin~ and fftout~ the vectorsize is the global one, it is not a subcircuit.
2. inside pfft~ the vectorsize is the fft size. (or probably twice the number you enter as argument)
3. but if you perform an operation such as framaccum~ does, it does not matter how long the vectors are. you or your external only have to make sure to adjust the process likewise when the eviroment changes.
so that is similar to the fact that you have to use dspstate~ and not a constant if you want to calculate nyquist - or to the fact that you can do delay~ 1 and delay 100000 no matter the vectorsize.
my conclusion is that #2. is done like it is, because you would not have any benefit in an fft patch from a low vectorsize; it simply make sense to process framewise.
hopefully >50% of that is correct.
just to add, pfft~ is like a poly~ wrapper for fft operations(works a bit like the poly~ object). same way you can set poly~ with an independent vector size, is the same way in which pfft~ handles its own vector size to match the fft-size chosen.
however, to clarify further: if you have the 'fullspectrum' flag set, then it's the same number you enter as argument, otherwise, the vector-size within pfft~ is actually half that argument. furthermore, if you're wondering how it might handle vector-size outside of pfft~ translating into the size within pfft~, there is some creative buffering magic that helps them match before coming in(before fftin~), and after going out(after fftout~).
at least this is how pfft~ worked back in Max5, and unless they changed it drastically since then, is probably the same way now. i can't tell you more due to the NDA i signed long ago, hope it helps, tho. 🕴🏼
raja what about smaller? what if you do an FFT 4 while the mother patch has vs32?
(wouldnt it be a waste of CPU? i.e. the opposite effect of why at 4096 it uses 4096?)
all i can say is
your intuition that it's an extra tax on CPU
('waste' might be considered a subjective word depending on context)
for such a case, is good to follow :)
('buffering magic' is just my own generic term for the way it translates either way, only pointing out the FFTsize is the vectorsize within a pfft~ with the caveat above about 'full spectrum flag' 🧙)
that's all i can say 😇
👻🕴🏼👽🕴🏼👻