Frequency domain simulation of temporal domain processes, FFT stuff

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

It's probably worth pointing out that what we're talking about here are single cycle periodic waveforms, not arbitrary samples. Imagine in the simplest case that this waveform is just a single sine wave. How fast you play this waveform will determine the pitch/frequency. Now, if you alter the waveform so that it's two sine waves next to each other then the pitch will be...twice what it was. But the point is, how fast you play the single cycle waveform, taking into account sample rate etc, will determine the pitch/frequency.

Ultimately a lot of this stuff now is only going to click once you start to write a little code and experiment.

Post

Music Engineer wrote: Wed Apr 24, 2024 7:00 pm Realtime additive synthesis is an entirely different story - you'd typically use some sort of (hopefully heavily parallelized) oscillator bank rather than an IFFT. At least, that's what I would use. You can do additive synthesis with IFFT, too - but it's quite unnatural, clunky and messy.
It kinda all converges. You can view FFT bins as a bank of sine oscillators. Each bin with two numbers representing magnitude and phase.

Then using IDFT you end up with a sum of all bins up to your Nyquist for each sample. If you optimise using sin/cos recurrence and SIMD (it's one of those embarrassingly parallel situations) then you're pretty much doing the same operations as combining a bunch of sine oscillators.

But...as you mentioned, doing this for an additive synth means you're doing all this per-sample whereas with an IFFT wavetable setup you can pull back and generate the time domain wave every 'n' samples.

Post

rou58 wrote: Wed Apr 24, 2024 7:36 pm Then you scale the spectral data depending on what the current pitch is resolved to be relative to the root pitch of the data.
Scaling the spectral data would be a rather tricky thing - you would have to think about interpolation, smoothing, etc. and you would almost certainly get artifacts from such a strategy. To determine the pitch, I'd rather cycle through IFFT result faster or slower. Much easier to get right - or rather hard to get wrong, actually.
Are you saying each individual partial (sine wave) is being played, so like a 64 part additive table would be played by 64 sine wave oscillators? If so, that seems insane to me. Why would you not just IFFT and play with a single oscillator?
An oscillator bank is much more flexible than a block-based IFFT. First of all, you can have arbitrary frequencies rather than being restricted to harmonics of some fundamental. You could even make the instantaneous frequencies and amplitudes time-varying. Try doing that with an IFFT based approach and you'll see what I mean by "messy". With efficient recursive sine oscillators and SIMD (like, say, doing 8 of them in parallel), 64 should actually not be such a big deal - but 1024 would still be.
Last edited by Music Engineer on Thu Apr 25, 2024 9:10 pm, edited 2 times in total.
My website: rs-met.com, My presences on: YouTube, GitHub, Facebook

Post

Yeah I think I just need to get my hands dirty. I have more than enough info between these two threads to set me on the right path, so thanks everyone for helping. :)

Post

Music Engineer wrote: Thu Apr 25, 2024 2:52 pmWith efficient recursive sine oscillators and SIMD (like, say, doing 8 of them in parallel), 64 should actually not be such a big deal - but 1024 would still be.
1024 recursive sine-oscillators with SIMD is not a huge deal computationally, but you'll also need a ton of control data and state data and probably interpolation for said control data and what not to actually do something useful with it.. and that's kinda more expensive then that 1024 sine-oscillators themselves.. It's doable, but .. not exactly free.

Also the common theme with these costs is that they can end up being super-linear.. like 1024 sines might actually be more than 16 times more expensive than 64 sines.. simply because you're more likely to run into cache/bandwidth issues and less likely to get anything much out of register allocation, etc.

Post

JustinJ -- In that other thread you say: "Thinking aloud, I could morph the 2k waveform, scale down according to note, FFT, band-limit, morph spectrum and then iFFT."

Wouldn't you want to band-limit after modifying the spectrum, not before?

Post

rou58 wrote: Sat Apr 27, 2024 9:09 pm Wouldn't you want to band-limit after modifying the spectrum, not before?
Technically yeah.. but when modifying the spectrum you can also simply avoid creating partials that would end up being band-limited, which saves some processing too.

Post

rou58 wrote: Sat Apr 27, 2024 9:09 pm JustinJ -- In that other thread you say: "Thinking aloud, I could morph the 2k waveform, scale down according to note, FFT, band-limit, morph spectrum and then iFFT."

Wouldn't you want to band-limit after modifying the spectrum, not before?
Band-limiting the FFT means zeroing bins that would exceed Nyquist when played. Those bins don't need to be affected by any spectral morphing or other manipulations. I mean, if it's easier to apply spectral manipulation then zero the bins, that works too. As long as those bins are zeroed when you do the iFFT, you're good.

Post Reply

Return to “DSP and Plugin Development”