I’d also encountered amplitude modulation artefacts with FFT. The informal explanation that I finally came up with is: the AM artefacts don’t happen when each FFT window (or grain – I think FFT is a special case of granular synthesis) has a Hann window and the overlap is an even integer, because then the fade-in is the first quarter of a sin^2 wave and the fade-out is the first quarter of cos^2, and sin^2(x) + cos^2(x) = 1, so the total aggregate envelope is a constant = no AM.
In SC, FFT by default applies a half-sine envelope to the time-domain samples before FFT-ing, and IFFT applies another identical envelope to the resulting time-domain samples. Multiplying by the same envelope twice = squaring it = sin^2 = Hann window. So FFT → IFFT without anything else should sound perfectly smooth.
Audio → half-sine window → FFT encodes the window as a non-intuitive interaction among the FFT’s partials. Messing around with the partials will distort this envelope. Then at the end you get “not a half-sine” times “half-sine” = not a Hann window. So the sum of midpoint-aligned overlapping windows will no longer be a constant, and AM will factor into the result. Messing around with the partials is, of course, the point! So the default windowing may or may not work for every application. You might be able to try other window types, probably discussed in FFT help.
Alternately, it was just announced that DynGen can now do FFT! (“Add FFT support via phase vocoder.”) This might let you handle windowing in a more flexible way (though I haven’t looked at details) and it looks like it will be a great solution to the long-standing “I want a new FFT operation but I don’t want to use C++, and pvcollect isn’t doing the job” problem.
hjh