Getting "normal" signals into pfft~

Jan 5, 2007 at 3:46pm

Getting "normal" signals into pfft~

Hi, dear MaxMSP-forum people..

Is there any way (besides using a send~ and receive~ pair) to get an ordinary signal into my pfft subpatch without fourier-analyzing it? So I send my pfft-patch a constant signal of “2.” and I want to use this number inside the patch.

Sounds pretty reasonable, don’t it?

– Tb

#29513
Jan 5, 2007 at 4:45pm

#92401
Jan 5, 2007 at 4:54pm

On 05-janv.-07, at 16:46, Tarik wrote:

>
> Hi, dear MaxMSP-forum people..
>
> Is there any way (besides using a send~ and receive~ pair) to get an
> ordinary signal into my pfft subpatch without fourier-analyzing it? So
> I send my pfft-patch a constant signal of “2.” and I want to use this
> number inside the patch

[fftin~ nofft], but you should read the manual about this, I think
there is some trick I can’t remember now!

p

#92402
Jan 6, 2007 at 11:14am

Yes, sorry I forgot to tell this in the first post, but also the nofft argument to fftin~ just doesn’t work for me. Only with an overlap of 2 will this work, but in all other cases the input signal will always be seen as 0. And I really nead a bigger overlap.

– Tb

#92403
Jan 6, 2007 at 12:04pm

On 06 Jan 2007, at 12:14, Tarik wrote:

>
> Yes, sorry I forgot to tell this in the first post, but also the
> nofft argument to fftin~ just doesn’t work for me. Only with an
> overlap of 2 will this work, but in all other cases the input
> signal will always be seen as 0. And I really nead a bigger overlap.

works as expected over here.
patch?

#92404
Jan 6, 2007 at 12:34pm

On 06-janv.-07, at 13:04, vb wrote:

> On 06 Jan 2007, at 12:14, Tarik wrote:
>
>>
>> Yes, sorry I forgot to tell this in the first post, but also the
>> nofft argument to fftin~ just doesn’t work for me. Only with an
>> overlap of 2 will this work, but in all other cases the input signal
>> will always be seen as 0. And I really nead a bigger overlap.
>
> works as expected over here.
> patch?

send/receive?

#92405
Jan 6, 2007 at 7:12pm

Sorry, my mistake… I don’t know what went wrong but the nofft argument seems to be working fine now I restarted the computer.

Thanks for the help!

Tb

#92406
Jan 7, 2007 at 1:02pm

Ah, it seems to be something else:

The nofft argument doesn’t work when I give my fftin~ object a full spectrum flag (like in “fftin~ 1024 4 0 1″). Then no signals seem to get into my pfft~ patcher. So it seems like I have to start working with send/receive objects after all…

- Tb

#92407
Jan 7, 2007 at 1:04pm

Ehmmm… I meant to say “pfft~ 1024 4 0 1″ of course!

#92408
Jan 8, 2007 at 3:07pm

On 07 Jan 2007, at 14:02, Tarik wrote:
>
> Ah, it seems to be something else:
>
> The nofft argument doesn’t work when I give my fftin~ object a full
> spectrum flag (like in “fftin~ 1024 4 0 1″). Then no signals seem
> to get into my pfft~ patcher. So it seems like I have to start
> working with send/receive objects after all…
>
hm, the signal gets into the pfft~, but it is strangely modulated,
which makes me think there is a BUG involved.
same happens to fftout~ x nofft.

don’t know whats going on.
but i do get a lot of crashes when trying to use these nofft inlets/
outlets…

below is a patch to observe the modulation. check the capture~
objects inside pfft (and outside).

what are you actually doing that you need the full fft spectrum?

volker.

(maxmsp 4.5.6)

/* save as testSig.pfft */

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 235 195 50 196617 capture~;
#P newex 253 167 50 196617 capture~;
#P user number~ 292 144 351 159 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P newex 359 187 94 196617 count~ 0 2048 1 1;
#P newex 205 294 76 196617 fftout~ 2 nofft;
#P newex 336 244 57 196617 poke~ mag;
#P newex 253 86 70 196617 fftin~ 2 nofft;
#P newex 119 197 27 196617 *~;
#P newex 119 236 53 196617 poltocar~;
#P newex 119 125 53 196617 cartopol~;
#P newex 136 170 30 196617 >~ 1;
#P newex 119 268 51 196617 fftout~ 1;
#P newex 119 86 97 196617 fftin~ 1;
#P connect 9 0 7 1;
#P connect 5 0 4 0;
#P fasten 5 0 7 0 124 229 341 229;
#P connect 6 0 2 1;
#P connect 6 0 11 0;
#P connect 6 0 10 0;
#P connect 0 2 12 0;
#P connect 0 2 8 0;
#P connect 3 1 4 1;
#P connect 0 1 3 1;
#P connect 2 0 5 1;
#P connect 3 0 5 0;
#P connect 3 0 2 0;
#P connect 4 0 1 0;
#P connect 0 0 3 0;
#P window clipboard copycount 13;

/* main patch */

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 60 178 41 196617 *~ 0.2;
#P newex 60 114 39 196617 noise~;
#P newex 186 179 50 196617 capture~;
#P hidden newex 331 39 48 196617 loadbang;
#P newex 381 60 80 196617 buffer~ mag 24;
#P message 331 61 45 196617 set mag;
#P user waveform~ 331 81 363 137 3 9;
#W mode select;
#W mouseoutput none;
#W clipdraw 1;
#W unit samples;
#W grid 22.675737;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 0;
#W vzoom 17.;
#W voffset 1.;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 146 179 217;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P user ezdac~ 47 226 91 259 0;
#P flonum 186 90 35 9 0. 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 186 115 44 196617 sig~ 11;
#P newex 60 143 136 196617 pfft~ testSig.pfft 512 4 0 1;
#P connect 10 0 3 0;
#P connect 9 0 0 0;
#P connect 0 0 10 0;
#P connect 10 0 3 1;
#P connect 2 0 1 0;
#P connect 1 0 0 1;
#P connect 0 1 8 0;
#P hidden connect 5 0 4 0;
#P hidden connect 7 0 5 0;
#P window clipboard copycount 11;

#92409
Jan 8, 2007 at 9:05pm

#92410
Jan 9, 2007 at 2:01pm

Hmmm, that’s a pretty nice effect actually. Kinda reminds me of Robert Henke’s Signal to Noise album. Which doesn’t change the fact that this is not supposed to happen! Looks like a BUG to me too..

I need the full spectrum because I’m using a patch similar to the one that is demonstrated in the phase vocoder tutorial by Dudas. I must admit that I don’t exactly know why this is so essential, but I do know that it is…

- Tb

#92411
Jan 11, 2007 at 1:21pm

Tarik wrote:
> I need the full spectrum because I’m using a patch similar to the one
> that is demonstrated in the phase vocoder tutorial by Dudas. I must
> admit that I don’t exactly know why this is so essential, but I do
> know that it is…

For sure a phasevocoder is not one of those “esoteric DSP” processes
which are mentioned in the pfft docs. And the phase vocoder example in
your examples folder doesn’t use it either (And there is even a credit
for Dudas…).

I know that its not essential for a phase vocoder, on the contrary it
would unecessarily complicate it and eat more CPU as well…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#92412
Jan 11, 2007 at 2:10pm

Dudas’ words, from the phase vocoder tutorial
( http://www.cycling74.com/story/2006/11/2/113327/823 ):

“The fft~ object performs a full-spectrum FFT (i.e. mirrored), so we consequently need to make the pfft~ object behave the same way, so the fft~ can work in sync with the FFT frames processed inside the pfft~ object. We need to make a few changes to the default way that pfft~ deals with the STFT.

First, we first need to tell the pfft~ object to process full-spectrum FFT frames, instead of the default “spectral frame” which is half the FFT size (up to half the Nyquist).”

I guess that it must be esoteric after all.. Although my guts tell me that – indeed – this is taking up too much cpu and should be done in a “cheaper” way, my guts also tell me that Dudas really knows what he’s talking about. And for sure, I wouldn’t know any alternatives to his sollution.

– Tb

#92413
Jan 11, 2007 at 4:16pm

#92414
Jan 12, 2007 at 6:43am

#92415

You must be logged in to reply to this topic.