tommi

before I give up to desperation, I beg someone to answer this:

is it possible to feed SIGNAL in a pfft~ without having it processed by fftin~?

the "in~" help file says that it "defines a signal inlet for a patcher loaded by poly~ or pfft~", so it seemed like the perfect choice... problem is that any signal fed to it never made it into the pfft~. I plugged a "sig~ 1." into it and inside the pfft~ the meter stayed at "0."

Messing around with the documentation I noticed that the "pfft~" help file says: "Patchers loaded into a pfft~ object can only be given signal inlets by fftin~ objects within the patch."

I really need to feed signal as it is into the patcher, because I need to cut off all data regarding certain bins and I need absolute sync on this...

hi everyone,
before I give up to desperation, I beg someone to answer this:
is it possible to feed SIGNAL in a pfft~ without having it processed by fftin~?

Messing around with the documentation I noticed that the "pfft~" help file says: "Patchers loaded into a pfft~ object can only be given signal inlets by fftin~ objects within the patch."
!

I really need to feed signal as it is into the patcher, because I need to cut off all data regarding certain bins and I need absolute sync on this... 

If you don't want a signal input windowed so it can be used as a control signal inside the [pfft~] subpatch you can use [fftin~ 1 nofft], this is documented in the reference page.

I'm afraid this is true for the fftout~ object, and referenced as well.

I still can't find anything like that about fftin~... could you please address it to me?

then, of course I tried it anyway but... no hope for me (excuse the pun)! the object still has 3 outlets and none of them will let the virgin signal pass!

mhhh...
I'm afraid this is true for the fftout~ object, and referenced as well.
I still can't find anything like that about fftin~... could you please address it to me?

It works for me, have a look at the files I've zipped and attached.

I was testing your suggestion on my own and was about to write back to you but you've been quicker... 

Yes you were absolutely right. I thought of the "nofft" argument before posting the first message... but I forgot to type in the inlet number so it resulted in the brown object I deleted superficially.

anyway I still be more thankful to you if you would be so kind as to tell me where this topic is referenced, because I think C74 should be notified about any major lack of documentation.

And, it the signal passing through all three outlets? isn't this three times expensive from a CPU point of view? and what about the wrong (?) documentation of "in~"?

dear lh, 
thank you very much for your support!
I was testing your suggestion on my own and was about to write back to you but you've been quicker... 
Yes you were absolutely right. I thought of the "nofft" argument before posting the first message... but I forgot to type in the inlet number so it resulted in the brown object I deleted superficially.

The "nofft" argument is mentioned on the [fftin~] reference page, there's a link to the object-specific entry in the top right corner of every help file. I agree the entry in the [in~] help file regarding use in [pfft~] subpatches isn't helpful.

and for the meantime, there is [receive~]

and for  the meantime, there is [receive~]


all right all right, it is written in the reference page... sorry. 

and receive~ will also do. thank you guys.

but since I started this topic, I'd like to ask you also what does this exactly mean that "it will echo the first half of its input sample window to its real output and the second half to its imaginary output"?

anyway it says that this makes sense only if overlap is set to 2 in the pfft~ which is not my case

all right all right, it is written in the reference page... sorry. 
and receive~ will also do. thank you guys.

but since I started this topic, I'd like to ask you also what does this exactly mean that "it will echo the first half of its input sample window to its real output and the second half to its imaginary output"?
do I have to sum them?
anyway it says that this makes sense only if overlap is set to 2 in the pfft~ which is not my case 

tommi wrote on Fri, 04 September 2009 01:39

"it will echo the first half of its input sample window to its real output and the second half to its imaginary output"?

Your pfft patch may be crunching samples at a different rate to the parent patch - nofft has always been difficult to work with. The problem is that for a given frame there are twice the number of input samples as fft bins, so the first half get put through one input, and the second half through the next. You're not supposed to sum them.

Also the receive~ approach is likely to produce unexpected results (probably missing signal, due to mismatched vector sizes). I'd strongly advise against this, and it's not going to work properly. What exactly are you trying to do? Maybe you don't need to pass the whole signal into the pfft~? There may well be a better, and more reliable approach.

tommi wrote on Fri, 04 September 2009 01:39"it will echo the first half of its input sample window to its real output and the second half to its imaginary output"?
do I have to sum them?
anyway it says that this makes sense only if overlap is set to 2 in the pfft~ which is not my case 

Hi, Alex, yes I have to confirm that both fftin nofft and receive are not working correctly... 

I needed to feed the signal into the pfft because I wanted a bin not to be revealed and I hoped that working with signal would have helped avoiding timing problems. I am feeding a sine wave into the pfft and changing its frequency, I want the sine to be "transparent" to the pfft, but when the freq changes pfft reports energy in some bin (I did not care to find out which one exactly...). then it keeps on ignoring the right bin but, since the frequency has to change almost 200 times, the energy reported at each freq shift is spoiling the results...

anyway, maybe pfft is not the right object to execute this routine, I'm finding alternative strategies...

I hope that C74 will take care of this in the next update!

Hi, Alex, yes I have to confirm that both fftin nofft and receive are not working correctly... 
I needed to feed the signal into the pfft because I wanted a bin not to be revealed and I hoped that working with signal would have helped avoiding timing problems. I am feeding a sine wave into the pfft and changing its frequency, I want the sine to be "transparent" to the pfft, but when the freq changes pfft reports energy in some bin (I did not care to find out which one exactly...). then it keeps on ignoring the right bin but, since the frequency has to change almost 200 times, the energy reported at each freq shift is spoiling the results...

I hope that C74 will take care of this in the next update! 

in~!?