when and why to use vectral~

Aug 24, 2006 at 5:33am

when and why to use vectral~

Hi,

I am studying FFT right now and find that vectral~ sometimes appear in these FFT related patches. I read the manual and help file but could not understand when and why we need to use it.

Could anybody explain more clearly ?

Thanks.

Chien-Wen

#27282
Aug 24, 2006 at 7:16am

if I dont remember bad (but too less sleep hours i’ve got last night
to tell the truth :-p)
vectral~ lets you do some operation between succesive buffers and
create very useful ramps for producing reverbs and delays.
Technically vectral can act like a smoothing filter that doesn’t work
sample by sample
but bin by bin: that means that it works with samples, but it doesnt
act through consecutive samples, but escaping samples.
Because of this feature you can actually do better things easily in fft.

i remember once, in Basel (ch) , a great teacher from Cycling, mr
R.D., tell about vectral… ” it was there? was it always there???”

he wanted it badly :-)

hope this helps,
mabe some other can be more specific

cheers,

tom

Il giorno 24/ago/06, alle ore 07:33, Cheng Chien-Wen ha scritto:

>
> Hi,
>
> I am studying FFT right now and find that vectral~ sometimes appear
> in these FFT related patches. I read the manual and help file but
> could not understand when and why we need to use it.
>
> Could anybody explain more clearly ?
>
> Thanks.
>
> Chien-Wen
>
>
>

#82375
Aug 24, 2006 at 7:14pm

It’s just a bin based envelope follower, so it’s useful for anything
which typical envelope followers are good for, perhaps most common of
which being dynamics processing like noise gating, compression,
expansion or visualization purposes like an eq meter. However,
there’s a number of more interesting things which can be done like
tying them to oscillator bank frequency or vocoder filter maps,
etc…I think my initial reason for making it was to assist a patch
that performed FFT based noise reduction/spectral thinning in the
vein of the old favorite ionizer.

-Joshua

#82376
Aug 26, 2006 at 8:48pm

Thanks for the explanation.

Are there any example patches or tutorials that can examplify the use of vectral~ ?

It seems that the output of vectral~ is just like some amplitude info, doesn’t it ?

#82377
Aug 30, 2006 at 12:48am

I observed that the data from vectral~ output is frequently connected to the fft~ real and imagery ouput as if it is used to scale the amplitude. But I am still confused about how vectral~ works. Since FFT deals with frequency domain, I feel confused about this bin-based envelop follower which seems to be something dealing with time-domain stuff. What exactly is the output of vectral~ ? The overall amplitude data for each consecutive FFT frame in time domain, the amplitude data for each frequency bin in a FFT frame, or something else ?

Could someone help explain more ?

Thanks.

#82378
Aug 30, 2006 at 1:35am

#82379
Aug 30, 2006 at 3:10am

Here is my explanation:

Normally if you used something like rampsmooth in pfft, rampsmooth would interpolate between the values of successive bin indexes.
i.e. the interpolation all happens within one frame.

With vectral, the interpolation occurs ACROSS separate frames. So for example if you were running a pfft with a FFT size of 8, you get 8 samples per frame. Each of these samples represents one eigth of the frequency spectrum, and are indexed from 0 to 7.

You dont want to be interpolating from index 1 to index 2 to index 3 etc.
You want to interpolate between index 1 of the first frame and index 1 of the second frame.

When vectral is wired to receive the index values from an fftin object, vectral knows which frequency band is which. This way, when it receives a value from index 1, it holds that value and waits until the next index 1 comes around and then performs its calculations.

I hope this helps, or at least didn’t hurt. :]

#82380
Aug 30, 2006 at 4:10am

#82381
Aug 30, 2006 at 6:28am

Thank you very much. I understand it a little better now.
Tht patch posted above is also very interesting.

But the patch posted above uses vectral~ differently from what I saw in the following patch. The following patch is part of someone’s piece which I am studying. When I take part of it out of the original patch to test it, it does not output any sound from pfft subpatch.

Could any one see what’s wrong with it ?
I am thinking that the programmer uses “bin shift” (mentioned in MSP reference) to transform the sound. (I have no idea what bin shift is, but I know it does transform the sound.) But I don’t know if the lookup table connected to the rightmost output works or not. Perhaps the lookup table is used to scale the FFT output. However, the patch does not output any sound from FFT. Any idea ?

main patch:

max v2;
#N vpatcher 100 100 1071 637;
#P origin 0 -6;
#N vpreset 1;
#X append 1 1 16 60 358 number int 12 ; 27 200 273 number int 10 ;;
#P preset 273 21 47 27;
#P user gain~ 110 255 24 100 158 0 1.071519 7.94321 10.;
#P window setfont “Sans Serif” 9.;
#P number 273 200 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P hidden newex 522 31 65 9109513 loadmess -1;
#P hidden newex 455 32 60 9109513 loadmess 1;
#P user meter~ 67 118 147 131 50 0 168 0 103 103 103 255 153 0 255 0 0 217 217 0 153 186 0 12 3 3 3 3;
#P toggle 197 30 15 0;
#P message 197 47 43 9109513 loop $1;
#P toggle 84 377 15 0;
#P user gain~ 147 257 24 100 158 0 1.071519 7.94321 10.;
#P newex 147 406 31 9109513 dac~;
#P window linecount 3;
#P comment 446 179 150 9109513 – deltaclip ; limits the change in samples to be in the given range;
#P number 405 60 35 9 1 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 358 60 35 9 1 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P button 311 187 15 0;
#P flonum 405 171 35 9 0 0. 2 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 358 171 35 9 0. 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 311 204 105 9109513 pack deltaclip 1. -1.;
#P button 310 132 15 0;
#P flonum 404 116 35 9 1. 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 357 116 35 9 1. 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 310 149 104 9109513 pack slide 1. 1.;
#P window linecount 3;
#P comment 446 123 150 9109513 – slide ; logarithmic movement to new value;
#P button 311 76 15 0;
#P window linecount 1;
#P newex 311 93 104 9109513 pack rampsmooth 1 1;
#P window linecount 3;
#P comment 446 67 149 9109513 – rampsmooth ; linear ramp across up/down frames to the new value;
#P window linecount 1;
#P message 165 47 30 9109513 open;
#P toggle 147 47 15 0;
#P newex 147 233 141 9109513 pfft~ vectralinpfft.pfft 1024;
#N sfplay~ 1 120960 0 ;
#P newobj 147 77 44 9109513 sfplay~;
#P connect 0 0 24 0;
#P connect 0 0 28 0;
#P connect 2 0 0 0;
#P connect 3 0 0 0;
#P connect 22 0 0 0;
#P connect 0 0 1 0;
#P connect 12 0 1 0;
#P connect 8 0 1 0;
#P connect 5 0 1 0;
#P connect 1 0 20 0;
#P connect 28 0 19 0;
#P connect 21 0 19 0;
#P connect 20 0 19 0;
#P connect 28 0 19 1;
#P connect 20 0 19 1;
#P connect 23 0 22 0;
#P connect 29 0 27 0;
#P connect 27 0 1 1;
#P connect 10 0 11 0;
#P connect 9 0 11 0;
#P connect 11 0 8 0;
#P connect 17 0 6 0;
#P connect 16 0 6 0;
#P connect 6 0 5 0;
#P connect 14 0 15 0;
#P connect 13 0 15 0;
#P connect 15 0 12 0;
#P hidden connect 25 0 9 0;
#P connect 9 0 8 1;
#P connect 29 0 16 0;
#P hidden connect 25 0 16 0;
#P connect 16 0 5 1;
#P hidden connect 25 0 13 0;
#P connect 13 0 12 1;
#P hidden connect 25 0 10 0;
#P connect 10 0 8 2;
#P hidden connect 25 0 17 0;
#P connect 17 0 5 2;
#P hidden connect 26 0 14 0;
#P connect 14 0 12 2;
#P pop;

FFT subpatch (named “fft_test”).

max v2;
#N vpatcher 58 88 1007 543;
#P window setfont “Sans Serif” 9.;
#P newex 263 309 27 9109513 *~;
#P newex 183 413 45 9109513 fftout~ 1;
#P message 298 159 41 9109513 size $1;
#P newex 287 131 43 9109513 fftinfo~;
#P newex 347 159 37 9109513 abs~;
#N in 2;
#P newobj 374 81 23 9109513 in 2;
#P newex 374 104 38 9109513 sig~ 0;
#P newex 347 135 37 9109513 +~;
#N in 3;
#P newobj 380 190 25 9109513 in 3;
#P newex 507 58 69 9109513 index~ lookup;
#P newex 182 308 27 9109513 *~;
#P newex 372 244 145 9109513 vectral~ 512;
#P newex 181 37 177 9109513 fftin~ 1;
#P connect 0 0 2 0;
#P connect 2 0 11 0;
#P connect 1 0 2 1;
#P connect 12 0 11 1;
#P connect 0 1 12 0;
#P connect 1 0 12 1;
#P connect 9 1 10 0;
#P connect 0 2 5 0;
#P connect 5 0 8 0;
#P connect 10 0 1 0;
#P connect 4 0 1 0;
#P connect 8 0 1 0;
#P connect 7 0 6 0;
#P connect 6 0 5 1;
#P fasten 0 2 1 1 352 67 444 67;
#P connect 3 0 1 2;
#P connect 0 2 3 0;
#P pop;

#82382
Aug 30, 2006 at 8:21am

it should be amplitude for each bin

maybe joshua can tell us :-)

Il giorno 30/ago/06, alle ore 02:48, Cheng Chien-Wen ha scritto:

>
> I observed that the data from vectral~ output is frequently
> connected to the fft~ real and imagery ouput as if it is used to
> scale the amplitude. But I am still confused about how vectral~
> works. Since FFT deals with frequency domain, I feel confused about
> this bin-based envelop follower which seems to be something dealing
> with time-domain stuff. What exactly is the output of vectral~ ?
> The overall amplitude data for each consecutive FFT frame in time
> domain, the amplitude data for each frequency bin in a FFT frame,
> or something else ?
>
> Could someone help explain more ?
>
> Thanks.
>
>
>
>

#82383
Aug 30, 2006 at 12:32pm

#82384
Aug 30, 2006 at 12:38pm

#82385
Aug 30, 2006 at 6:42pm

On Aug 30, 2006, at 1:27 AM, tommaso perego wrote:

> it should be amplitude for each bin
> maybe joshua can tell us :-)

vectral~ is just a temporal data smoother for framebased data that is
serialized as an audio signal. What that data is and how or why to
use it is completely general.

Perhaps the confusion is over how a frame of information is
serialized as an audio signal, or what precisely a bin within a frame
is, but I’ll leave it to someone else to take the time to walk
through those points if there’s still confusion.

-Joshua

#82386
Sep 5, 2006 at 1:29pm

Cheng Chien-Wen wrote:
> I observed that the data from vectral~ output is frequently connected
> to the fft~ real and imagery ouput as if it is used to scale the
> amplitude. But I am still confused about how vectral~ works. Since
> FFT deals with frequency domain, I feel confused about this bin-based
> envelop follower which seems to be something dealing with time-domain
> stuff.

In mathematical land the frequency domain seem disconnected from the
time domain but then you’d need the whole duration of your piece as
latency to start processing it…
In the real fft world there remains a time aspect, you slice the signal
into short slices (the fft window size) within one slize you have no
time structure (but you can get that information back with ifft).
Outside you do have a time structure, the change from slice to slice.
But each slice is divided and ordered by frequency bins.
If you want to change the timestructure of a single bin (like for
example have an envelope follower) then you need tools like vectral,
frameaccum~, framedelta~.
If you would split each bin into a seperate signal processing chain, you
could downsample by the window size and process each bin as if it would
be a normal signal. But you would have to deal with two parts seperately
the real and imaginary parts or if you converted it, the amplitude and
phase. Yes, this is getting complicated, but consistent…

Stefan


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

#82387
Jul 6, 2007 at 5:06pm

hi,
i still have a question on how to use vectral~:

if i would like to manipulate the way, a sound develops in time,
across multiple frames, i have apply envelope following on both
real and imaginary data, or in polar value, magnitude and phase,
since both carry time information, is this true?

but as soon as i manipulate time, i seem to affect also frequency or phase?
i must admit i have some difficulties how to treat those 2 parameters seperately.

thank you!
kassian

#82388
Jul 7, 2007 at 10:22am

kassian schrieb:
> if i would like to manipulate the way, a sound develops in time,
> across multiple frames, i have apply envelope following on both
> real and imaginary data, or in polar value, magnitude and phase,
> since both carry time information, is this true?

Best is to try both (and more) ways and listen…

You might only want to change the amplitude part. Go experiment and
listen. I’d try vectral~ only on the magnitude and leave the phase
untouched as a starting point. Try to understand why it sounds like it
sounds… If this leads to too much artefacts, try to feed the phase
into framedelta~/phasewrap~ and after eventual processing into
frameaccum~…

Sometimes even randomisation of the phase does miracles… ;-)

You will also learn from listening to the difference in results for
varying frame sizes. Do the extremes (very small/very big…) to find
out what will be appropriate… (watch out the CPU usage though…)

Stefan


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

#82389
Jul 8, 2007 at 4:34am

ok thanks!
that

#82390

You must be logged in to reply to this topic.