Spectrum morphing using fast iFFT?

[Spogg]

Hi all

I would like to build a spectrum morphing synth to play around with. Before I do it the hard way with loads of oscillators etc. does anyone have a fast iFFT module running in DSP/ASM/Ruby? All the iFFT stuff I've found uses green so is only good for static partial levels. If I change the partial mix dynamically there are clicks and delays due to poor timing.
Alternatively, has anyone done this successfully using the green stuff, maybe by multiplexing the outputs from several iFFT modules to avoid clicking?

Cheers

Spogg

[martinvicanek]

Stream FFT had been a holy grail in the SM era, until some great men (MyCo and Trog did most of the job) finally made it happen in FS. However, due to FS limitations it is not easy to use: input and output are serialized, so you don't have random access to the Fourier components. That's probably the main reason why it has not been used very much. Anyway, go and see for yourself. Who knows, it might just as well be helpful for what you are after.

[Spogg]

Stream FFT had been a holy grail in the SM era, until some great men (MyCo and Trog did most of the job) finally made it happen in FS. However, due to FS limitations it is not easy to use: input and output are serialized, so you don't have random access to the Fourier components. That's probably the main reason why it has not been used very much. Anyway, go and see for yourself. Who knows, it might just as well be helpful for what you are after.

Thanks Martin.

This is clearly a huge and remarkable design but, as you imply, it's not suited to my idea. It's great for creating telephone or cheap radio effects on a piece of music though!

So, if I do this, it'll be the 120% CPU version I'm afraid

Thanks again

Spogg

[KG_is_back]

If someone (probably martin ) would be able to make ASM code for the 4 channel FFT I can make a ruby module that will modify the code for one's needs (rename input and output array, make it optionally poly-compatible, insert it into marked spot in ASM code from Code component, etc.). All I need is this to be true about the ASM code:

Code: Select all

1.
uses two pairs of arrays:
inR[N],inI[N] =input arrays for real and imaginary part respectively
outR[N],outI[N] =output arrays -||-
NOTE: 4channel signal -each 16byte chunk would be the real/imag part of 4sse channels.
2.
the code does not modify input arrays - just output arrays (this is mostly optional)
HINT: moving data form "in" to "out" using bit-reversal permutation can happen either before or after the core of FFT. In this case before FFT would be preferred
3.
must use "movaps xmm?,array[eax];" and "movaps array[eax],xmm?;" to read/write to/from arrays.
This is crucial for making it poly-compatible (I've learned some tricks to do that).
4.
two xmm registers must remain unused during entire code (again, for making it poly-compatible I need them).


I've tried to do it myself, but failed miserably (rage-quitted like 100 times).

I can provide testing schematic, which will include serializer/deserializer (you'd basically only have to write your asm code between marked comments in one of the ASM modules). I believe, some parts of the code may be reused from trog/myco's schematic (for example the rearranger calculation for the bit-reversal).

[Spogg]

This is well beyond my understanding of even the basic principles so maybe I should clarify what I would like before someone goes to a LOT of trouble...?

-Two graphs, or similar, which describe the amplitude of defined partials in the stream iFFT (don't care about phase!).
-A single 0-1 control input (ADSR, LFO) which can mix or pan between them so we hear a real-time blend between the two "graphs".
- Most important is this must be dead smooth with no clicks or dropouts waiting for ticks or calculations to complete.

Real-time modulation of individual partial levels would be a luxury but not essential.

Essentially I would like to experiment with the technique to see what can be achieved sonically and musically. My Quilcom Blender was only a cross-fade synth but I was surprised at what the technique could do. I suspect that Spectrum morphing could also be very interesting.
Of course the brute force way would be with loads of oscillators and "VCAs" but I fear for the CPU. It would probably have to be monophonic

Cheers

Spogg

[KG_is_back]

Oh... you can just use two additive oscs (it's in the FS toolbox or in one of the download packs) in parallel and mix them using mix-knob.

[Spogg]

Oh... you can just use two additive oscs (it's in the FS toolbox or in one of the download packs) in parallel and mix them using mix-knob.

I am a stupid old Vulcan and I didn't think this through (I'm 14.6% human after all)
If any two waveforms have static spectra then cross-fading would be the same as spectral cross-morphing and I've already explored cross-fading in my Blender synth.

To morph say a sinewave into a square wave is NOT the same as cross-fading between them and that's the principle I had in mind (what little I have left of one). This type of morphing would require each partial to be individually controlled and follow a pre-destined course of envelope and LFO modulation. Only one additive generator would then be required, with each partial fading in/out as appropriate. That's what I'd really like!

Cheers

Spogg

[KG_is_back]

I have given it some thought and there is probably no CPU cheap way to do it... few of my ideas:

A) You could use some FFT to recalculate at each sample, to get smooth transitions. But you'd have to do the iFFT N-times each sample to produce band-limited wavetable, like the one stock-oscillators use (it has beend discussed before, how these wavetables are generated). That's totally insane...

B) You could have two parallel oscs, and update their tables at regular intervals (alternating) and crossfade them using triangle wave LFO. Something like this:
1.update WT (wavetable) of osc1 and start fading from osc2 to osc1
2.once morphed fully to osc1, update WT of osc2 and start fading back.
3.repeat 1. and 2.
The FFTs and the crosfader LFO would run in mono. The LFO would be provided to the poly section via mono-to-poly module.
The problem with this is, you still need enormous numbers of FFT to happen at the same time (understand, like 1 per sample on average, assuming the lenght of the fade = size of FFT). That is still a pretty heavy shit.

Possible optimisations:
1) you may calculate non-bandlimited wavetable (which takes only 1 iFFT) and use other means to band-limit the oscs (for example via oversampling).

2) you may create partially bandlimited wavetable (it would have like 16waves(n), each having n/16 of top harmonics removed) and use little bit of oversampling to deal with the few that need removal.

All above-mentioned methods require the Trogs FFT to be tweaked a lot and also do some heavy mem-sharing. That's a massive project currently above my skills (mainly because of the FFT part)

[Spogg]

Thanks KG!

It seems that, as you say, any method would use loads of CPU so maybe simple is better.
After I've finished my percussion synth I'll knock something crude together just to experiment with the sound, even though it may be of little practical use. If it turns out to be interesting I'll share it of course.

Cheers

Spogg

[adic]

Hi, all.
I implemented simple DLLs of FFT/iFFT via using GSL (GNU Scientific Library).
I put the source code at the following site.
https://drive.google.com/file/d/0B9H5-6MQsad7cGpHT1JmMGIzNWc/view?usp=sharing