How is this done?

[BobF]

Hello gang,

I often see adds for commercial plugins that state things like our plugin has hundreds of filters, delays, and so on. Sometimes they even boast thousands. The plugins are sometimes even small, so my question is how can they do it? Are such plugins possible with Flowstone? I found it hard enough when I designed my 40 band Vocoder to keep the cpu load down, so what is the trick?

Thanks, BobF.....

[martinvicanek]

what is the trick?

... the first letter in FFT.

[Spogg]

Here's a related question (kinda)

If you make a plugin in FS that uses Assembler, pretty much for everything, will one made in say C++ (that has the exact same features) be more CPU efficient? Or would the better one be made in what used to called machine code, at least for the time-critcal elements?

I can't do any of this myself so the answer is really just for info.

Discuss...

Cheers

Spogg

[BobF]

Hello Again,

Martin, I see in Spoogs ASS (ha, ha) you created for his Spring reverb a chrip delay with 200 all pass filters. Is there any upper limit? What if you needed control of each one? Could this be done with delays , pitch shifters, frequency shifters, others filters, and so on also?

Thanks again, BobF.....

[Spogg]

When I was developing this spring effect I did a lot of investigation into using different Fc values per stage but the effect only ever got reduced in result quality. I’d researched (i.e. Googled) all I could find on the topic but Martin dived in and donated the 200 step filter to get me out of CPU hell. Previously 120 stages seemed like a reasonable maximum when considering the result Vs. CPU but 200 seemed to be the sweet spot and sounded just right to my ears (and memory of my own real one).

What I find fascinating about all pass filters is that phase shift relates to the frequencies present in the incoming audio. This phase shift acts like a frequency-dependant delay (especially when chained) and when fed back creates a wide-ranging dispersion of all the frequency elements. This dispersion gives the characteristic chirp or boing sound.

You could experiment by using more of the 200-stage filters in series or using Martin’s discreet all pass filters (which is where I started off).

I don’t personally know of another way of creating a non-quantised frequency dependant delay. You could have a Bandpass filter bank, like In a vocoder, with a separate delay for each filter’s output, but I doubt it would sound convincing as a spring effect. Plus it would almost inevitably be a bit CPU hungry. But why not experiment? No soldering is involved!

Cheers

Spogg

[KG_is_back]

so what is the trick?

Fast Fourier transform. It basically splits the signal into 2^N bands. Well, not quite - instead of putting out a the individual band as a waveform it outputs the magnitude and phase of corresponding sinewave at N-times slower samplerate. The operation is also reversible.

There are many operations that are extremely expensive in time-domain (ie. regular sample-by-sample signal) but are almost trivially simple in frequency-domain. Good example is the vocoder. In time-domain you need to split the signal into many many bands, extract the envelope from the input and apply it to the carrier signal. That means you need to do 3 calculations per band per sample.
In frequency domain this is as simple as merely multiplying the spectra every FFT window, which is effectively just 1 calculation per sample.

Can it be done in Flowstone? Well, yes, but it's rather hard to pull off. Flowstone is not designed to allow user to process input signal in frames or transfer arrays/frames between code components. Martin has implemented stream FFT and convolution in FS before, but it's not exactly a modular user-friendly design (though it is probably as user-friendly as it gets, given FS limitations).

If you make a plugin in FS that uses Assembler, pretty much for everything, will one made in say C++ (that has the exact same features) be more CPU efficient? Or would the better one be made in what used to called machine code, at least for the time-critcal elements?

It depends... generally the C++ version will be faster for two reasons. Firstly, C++ compilers are way better at optimizing than mere mortals, given the C++ code is well written. Secondly, in flowstone we are mostly limited to processing streams sample-by sample, while in C++ we are processing whole buffers/frames provided by the DAW, which allows you to be more efficient in respect to cashing in many scenarios.
TL;DR well written C++ will beat well written Flowstone/assembler almost every time.

[BobF]

Thanks KG_is_back,

"Flowstone is not designed to allow user to process input signal in frames or transfer arrays/frames between code components."

So for the layman such as my self, is there anyway a good programmer could create a module to do the above and then fft, ifft, dft, and so on modules anyone could us easily and with some good examples. I have played with Martins and others hundreds of times now trying to do different confiurations and have failed everytime. Any other suggestions? Do I need to provide an example or two of what I want to do? Anyone else wish this could be done, so all could use fft?

Later then, BobF.......

[KG_is_back]

From what I've heard, new version of FS has memref input component aka. it can receive a pointer to a memory block. In the past this could be done by "cheating" a little, by reading out the address of the mem or a frame and then passing it into the assembler as float, but it was rather unstable. I'm not sure if this is also usable in code component or is limited to assembler though.

With the method it is possible to process the input data in frames in the similar way frames work in ruby. Just like ruby frames, the input and output create an overhead, since you have to fill and empty them as buffers.