@scudly what do you mean with base it on a frameRate derived value exactly?
I usually update the variables just based on the draw() iterations (e.g. x += 1). I think that should work too though.
Maybe I formulated the question in the wrong way. The problem isn’t so much that the frameRate itself drops. As you say, it won’t drop the frameRate, but it will slow down compared to the real-world clock.
The problem is that the audio playback doesn’t slow down with it. If you overload a sketch with too many objects you’ll notice that frames are rendered slower than usual, but the audio playback stays consistent. The result of this is that there is an offset between frames and the playhead position, causing frames to be rendered with incorrect FFT values.
By the way: I feel that the standard processing sound and FFT classes are quite simple, so I’m currently looking at the Minim library (see GitHub - ddf/Minim: A Java audio library, designed to be used with Processing.)