FFT normalization factor depends on FFT frame size (which is equal to blocksize for fft~ & Co.), overlap, and window type.

In my experience you can normalize where ever you want: in time domain before FFT, in frequency domain, or in time domain after FFT. It is also possible to normalize in two steps, each of sqrt(normalization-factor), for example when you want the bin content normalized for certain processing or analysis jobs. Then you do one step before processing and the second after processing.

In frequency domain, you can either normalize amplitude of polar coefficients, or real and imaginary part of rectangular coefficients. This has no consequence for normalization factor.

If you would do normalization outside the reblocked subpatch, that is also possible, before or after FFT patch. But you must still consider blocksize and overlap.

You can verify all these possibilities by tweaking mentioned patch. The fact that normalization factor does not depend on the point in the process where you apply it, is convenient. However, for analysis or processing, that point of normalization does matter sometimes.

Consider for example a single-sample click: it's energy is spread over all frequency bins. With no normalization before spectral analysis, magnitude would be 1 for each bin. Next, consider a perfectly white noise, or a complex linear chirp over the full spectrum. With sqrt(normalization-factor) before analysis, the magnitude is 1 for each bin. Next, consider a pure sinusoid. With full normalization before analysis, the magnitude is 1 for a single bin, or the leaked equivalent of that.

You see, it depends on signal type how spectral magnitude can be shown independent of FFT size. Probably, the signals you want to process resemble a white noise rather than single pulses or full-scale pure sinusoids. So my guess is, that you would opt for the two-step normalization if you want to mix spectral data of different FFT sizes.

Good luck,

Katja

here's a way of spectral freezing using the running phase calculated by some cyclone objects. i remember it sounding a lot nicer than the above mentioned patch, but don't ask me for the exact mathematical reason.

the pvoc~ object is also nice for time stretching/freezing. if you use some circular buffers you can do nice time stretching of realtime input. i'll post a patch when i find the time to.

i've been trying around a lot with this kind of stuff recently, but i haven't found a way to get rid of the weird phasing/oscillations when time stretching is applied to spectral output. i guess it has to do with phase locking and channel interferences, but the maths are way over my head. i wish there were some more spectral objects that handle that kind of stuff better. the phasing sounds cool when you just freeze input though.

http://www.pdpatchrepo.info/hurleur/freeze.pd

Hello everyone.
Im polishing my PD skills and reading a lot about synthesis i stumbled upon additive synthesis and im making my patch to build waveforms using sine waves with this method of synthesis.
The problem i have is i found the default oscilloscope in PD not very good and since im new at PD i was wondering if anyone had the time to explain how to build a decent oscilloscope to make sure my additive synthesis methods are correct.

@slur said:

not realy
in granular synthesis you change the playbackrate of a small block and change the start position

These aren't really requirements for granular synthesis, though; they're just some of the many parameters that can be manipulated. Granular synthesis is pretty flexible and open-ended. This looks to me like some kind of granular time-stretching.

2randal: this one - Dodge, Charles and Thomas A. Jerse. Computer Music: synthesis, compsition and performance. New York: Schirmer Books, 1985. or just now i found this - http://books.google.com/books?id=_W9Ek2LmPNMC&printsec=frontcover&dq=Sound+Synthesis&hl=cs&sig=sFnEm6IeSKyOGJjvulwz5J4NLP0

@alistair said:

... I remember you describing the downfalls of using a commercially produced program against an open source program which is being renewed regularly

Hi Alistair,

I think my point there was actually the *advantage* of the commercial offering vis stability. It's great that FOSS applications are constantly up to date with new ideas and improvements, but this can work against you sometimes. Always be careful in upgrading to the latest versions and try to use the minimal set of units in your work until you know what is "permenant" and what is "fleeting". Some things just die off because their authors move on to ther things and nobody will adopt them to support.

For me it's extra difficult because I write a lot of Pd code for <b> others </b> to learn from, not just my own personal use..

I had a question about Open Music (I operate a Mac) against Pd. Open Music is certainly cheaper than msp (120€(OM) as opposed to the 600$ (msp)), and (so I'm told) has a strong spectral analysis/fft, and a good support system. I wonder if you had any opinions about this.

Sorry I do not know this software,

A few respected colleagues suggested OM to me; another remarked that "Pd is really old, and even quite slow!" - i didn't have time to get him to elaborate, but -
-I imagined he was talking about live concert situation, using acoustic instruments, which is what he and I do; perhaps involving real time granular synthesis, rapid shifting between granular setting , sampling/transposition, spatialisation and circular movement amongst speakers (this referring to the "spat" module in msp). These would be my areas of concern, just now.

I am afraid your colleague is misinformed. It's nonsense to suggest Pd is "slow" in any way because it's old. Software, unlike physical machines has a tendancy to get faster with time rather than slower (because it gets improved). If you look at the source of Pd you will see it's written in rather efficient vanilla C, that makes it run VERY fast indeed. The GUI which is TC isn't so fast, but that has nothing to do with it's performance.

hallo obi,
thanks for the post, I was trying to find a similar post you made, about, er, a month ago when someone (new to Pd) wanted to know comparisons between Pd and Maxmsp (and another prog.). I remember you describing the downfalls of using a commercially produced program against an open source program which is being renewed regularly; i just couldn't find it, it might've helped to've quoted the link...

I had a question about Open Music (I operate a Mac) against Pd. Open Music is certainly cheaper than msp (120€(OM) as opposed to the 600$ (msp)), and (so I'm told) has a strong spectral analysis/fft, and a good support system. I wonder if you had any opinions about this.
A few respected colleagues suggested OM to me; another remarked that "Pd is really old, and even quite slow!" - i didn't have time to get him to elaborate, but -
-I imagined he was talking about live concert situation, using acoustic instruments, which is what he and I do; perhaps involving real time granular synthesis, rapid shifting between granular setting , sampling/transposition, spatialisation and circular movement amongst speakers (this referring to the "spat" module in msp). These would be my areas of concern, just now.

"Frozen reverb" is a misnomer. It belongs in the Chindogu section along with real-time timestretching, inflatable dartboards, waterproof sponges and ashtrays for motorbikes. Why? Because reverb is by definition a time variant process, or a convolution of two signals one of which is the impulse response and one is the signal. Both change in time. What you kind of want is a spectral snapshot.

1. Claudes suggestion above, a large recirculating delay network running at 99.99999999% feedback.
   Advantages: Sounds really good, its a real reverb with a complex evolution that's just very long.
   Problems: It can go unstable and melt down the warp core. Claudes trick of zeroing teh feedback is foolproof, but it does require you to have an apropriate control level signal. Not good if you're feeding it from an audio only source.
   Note: the final spectrum is the sum of all spectra the sound passes through, which might be a bit too heavy. The more sound you add to it, with a longer more changing sound, the closer it eventually gets to noise.

2. A circular scanning window of the kind used in a timestretch algorithm
   Advantages: It's indefinitely stable, and you can slowly wobble the window to get a "frozen but still moving" sound
   Problems: Sounds crap because some periodicity from the windowing is always there.
   Note: The Eventide has this in its infiniverb patch. The final spectrum is controllable, it's just some point in the input sound "frozen" by stopping the window from scanning forwards (usually when the input decays below a threshold). Take the B.14 Rockafella sampler and write your input to the table. Use an [env~]-[delta] pair to find when the
   input starts to decay and then set the "precession percent" value to zero, the sound will freeze at that point.

3. Resynthesised spectral snapshot
   Advantages: Best technical solution, it sounds good and is indefinitely stable.
   Problems: It's a monster that will eat your CPUs liver with some fava beans and a nice Chianti.
   Note: 11.PianoReverb patch is included in the FFT examples. The description is something like "It punches in new partials when theres a peak that masks what's already there". You can only do this in the frequency domain. The final spectrum will be the maxima of the unique components in the last input sound that weren't in the previous sound. Just take the 11.PianoReverb patch in the FFT examples and turn the reverb time up to lots.

I was thinking dismissively about this today, "Crazy kids and their beat slicers..."
Then I remembered it's actualy non-trivial, in fact it can be a pig of problem to do properly.

May a suggest that it be split up into sensible software components.

The first two parts are easy really, the table manager for storing samples in arrays, flatfiles or whatever, and the resequencer or slice dumper that can nicely envelope each chunk and play it or write them all as incrementally named files somewhere.

The third part is the bitch. We need a beat detector that can find startpoints. Easy with a nice clean recording, but with the Amen beat for jungle - that's the trick. Some kind of spectral differential is called for hooked to a look-ahead and look-back inteligent zero detector. (want to catch them on a positive going phase) Crack this and you've basically done the hard work.

The sub-unit should take an arbitary sized file and return a list of indexes that correspond to the start of an event according to three or four spectral thresholds, one for high, mid and low events (hihat, snare and kick)

As an aside, I used Recycle way back, I don't know if they improved the algorithm significantly since but honestly I found it a piece of crap, really sloppy at false positives caused by clicks or dicsontinuities, really naive algorithm which always went for the minima before a beat even if it was obviously way too early. I had a production job for a band which involved a lot of beat cutting and in the end I ditched recycle and went for cutting them by hand in cool edit, much faster. Steinbergs programmers aren't idiots, which leads to me to think there's a lot to doing this well.

Hello,

Not sure about the real-time aspect (live unpredicable streaming or straight from a file that you can read let's say 20ms in advance?), but there is some hints in a beginning chapter of the P. Cook book, Real Sound Synthesis for Interactive Applications. The chapter is about wavetable synthesis if my memory is good enough ...

See : http://www.amazon.com/exec/obidos/tg/detail/-/1568811683/qid=108853467 0/sr=1-1/ref=sr_1_1/104-8251597-6652725?v=glance&s=books