ReaVerb ZL Question

[Shufflehound]

I love ReaVerb (and REAPER) to bits, but so far I haven't touched the zero-latency checkbox.

I was wondering, since we're given an OPTION to have zero-latency or not, does that mean there's some disadvantage to having ZL on? Especially since it's default set to off?
If not, why not have it on permanently?

Cheers!

[Shufflehound]

Bumpity

[Tod]

Originally Posted by Shufflehound

I love ReaVerb (and REAPER) to bits, but so far I haven't touched the zero-latency checkbox.

I was wondering, since we're given an OPTION to have zero-latency or not, does that mean there's some disadvantage to having ZL on? Especially since it's default set to off?
If not, why not have it on permanently?

Cheers!

I've never really checked or tested it, but I use it quite a bit too.

However, I only check the ZL box when I'm getting latency while playing my midi keyboard.

[Xenakios]

The ZL mode uses more CPU but it might not be obvious with a reasonable length IR. Try an IR of 30 seconds or more to better see the CPU load difference. On my Windows system a 30 second IR uses about 0.2% maximum in non-ZL mode and about 0.5% maximum in ZL mode. Both tested with max FFT size of 16384.

[Bri1]

Both tested with max FFT size of 16384.

^ try the minimum 32 fft size-- seems to be reversed in what hit it makes..?
basically locks up here.. :/

rt cpu =over 1000% and counting... !! plz fix this devs!!

[Xenakios]

Originally Posted by Bri1

^ try the minimum 32 fft size-- seems to be reversed in what hit it makes..?
basically locks up here.. :/

Yeah both modes are completely unusable here with that FFT size with a 30 second IR.

[Bri1]

yes-sorry to be pointing errors anywhere --certainly do not like to complain or report anything--but regularly find holes-- great ship!! but it has many 'holes'.
stabilize-- then-- energize!!!

[EvilDragon]

That's not an error really. The smaller the FFT size the more of a burden it is for CPU, AFAIK. So if you have a really long IR and a very small FFT size, brace for impact. These are FFT basics.

[Dr Bob]

… and I expect Justin uses FFTW ??? Or even his own even FFTW :-)

dB

[Xenakios]

Originally Posted by Dr Bob

… and I expect Justin uses FFTW ??? Or even his own even FFTW :-)

It's not FFTW, but some old code from the 1990's. FFTW would be nice but it's expensive (as in $$$$) to use for proprietary projects. Changing to that might also require rewriting things in WDL, Reaper, ReaPlugs and JesuSonic...So I am not seeing that happening anytime soon.

[Bri1]

users could try this 2 chain- report bugs to devs if any..

STY 2verbolutionz.RfxChain
even using a single echo generator seems to 'output' 1 channel according to text..
changing fft sizes in other fx seems to not suffer the same performance strains..dunno..

check by changing to much lower fft on each instance--it depends on how long it runs for i think...

[Shufflehound]

Yeah a small FTT size means more analysis to do I'm pretty sure. Thanks for the answers guys, really cleared things up!

[Bri1]

Yeah a small FTT size means more analysis to do I'm pretty sure. Thanks for the answers guys, really cleared things up!

^ really?

hmm-to me_ all this appears as clear as mississippi mud.
i not actually sure some days,wether i actually share the same physical reality as others are... strange =) lol
it's just...we would not want cockos being 'responsible' for damaging peoples chips--would we?

some settings and functions in reaper are very very usefull-some can actually damage. so crak on m8!

[Justin]

In ReaVerb the smaller FFT size means more CPU use, not so much because of the FFT itself, but because of the (many) additional complex multiplications involved... anybody want to optimize WDL_CONVO_CplxMul2() and WDL_CONVO_CplxMul3(), be my guest.

[Shufflehound]

Originally Posted by Justin

In ReaVerb the smaller FFT size means more CPU use, not so much because of the FFT itself, but because of the (many) additional complex multiplications involved

I assumed it was more 'cause a smaller FFT size would mean having more frequency components packed together? I guess it doesn't mean what I thought it did.

[EvilDragon]

Originally Posted by Shufflehound

I assumed it was more 'cause a smaller FFT size would mean having more frequency components packed together? I guess it doesn't mean what I thought it did.

That's exactly the reason (instead of processing a few big chunks across frequency spectrum, you have a lot smaller ones - which is also why the spectrum meters get more precise as you choose lower FFT sizes - they're simply focusing on many smaller freq bands, rather than fewer large ones), and this pulls the additional complex multiplications that Justin is talking about, with it. So yeah, smaller FFT size = /much/ more CPU.

Let that sink in, Bri.

[Shufflehound]

Originally Posted by EvilDragon

That's exactly the reason, and this pulls the additional complex multiplications that Justin is talking about, with it. So yeah, smaller FFT size = /much/ more CPU.

Let that sink in, Bri.

That spells it out quite nicely.

Curious what the difference between ZL and not with different FFT settings in terms of CPU usage would be.

[Jeffsounds]

So, what would happen if you mixed with max FFT and rendered with lowest FFT? Any difference in sound at the end?

[Bri1]

So yeah, smaller FFT size = /much/ more CPU.

Let that sink in, Bri.

lolz--it already sunk ages ago-- having that option can sink this ship--so is it not just better to remove it? or,optimize-as suggested.

what actual realworld advantages is there crippling a daw with a simple single setting?

seeing none at this moment,other than greater resolution at render time...
oh +the width... sighz-- needs some tlc plz devs-- this is a core plug.
being a fan sometimes just is not enough!

[Xenakios]

Originally Posted by Jeffsounds

So, what would happen if you mixed with max FFT and rendered with lowest FFT? Any difference in sound at the end?

With convolution, the FFT size doesn't affect the sound. (It's a very particular FFT based algorithm, pretty much all other FFT algorithms will have huge differences in the sound when the FFT size is changed.)

[mschnell]

In fact the FFT size puts a low limit to the processed frequency range (= fftsite * samplerate).

E.g. a filter done by FFT just passes through any frequency below, as for the FFT algorithm this is considered DC.

Hence I suppose a convolution algorithm also will not process these low frequencies but pass them trough multiplied with the power of the appropriate low frequencies in the (static) impulse file (using the DC bins [0] of both signals). I recon this does affect the sound.

-Michael

[Xenakios]

Originally Posted by mschnell

In fact the FFT size puts a low limit to the processed frequency range (= fftsite * samplerate).

No, no, no, for the millionth time : no. Convolution does not work that way. The FFT is just used as a way to do the same calculations faster that could also be done in the time domain with brute force.

[Justin]

Originally Posted by Xenakios

No, no, no, for the millionth time : no. Convolution does not work that way.

Correct. The parameters for FFT size and ZL etc *only* affect PDC and performance characteristics— the resulting audio will be exactly the same.

[Bri1]

Correct. The parameters for FFT size and ZL etc *only* affect PDC and performance characteristics— the resulting audio will be exactly the same.

feature request Justin !! - please write a manual! - you seem to be 1 of the few that ACTUALLY understands what goes on+why.
thanks!!

[Shufflehound]

Originally Posted by Jeffsounds

So, what would happen if you mixed with max FFT and rendered with lowest FFT? Any difference in sound at the end?

Could always try a null test. Have the same sound and the same ReaVerb on separate tracks with different FFT settings and invert the phase of one of them.

[Bri1]

With convolution, the FFT size doesn't affect the sound.

hmm-this seems a contradiction-when clearly it does alter the sound in other reaplugs--no? they are not convolving though_eh?
try the eq with reafir set at lowest fft -try to draw precision shapes with it.. please explain the differences so people can get a better understanding of everything!!


@ Justin- soz--bit of a poor joke__ but technically_ you do go into much more detail here on the forum than the actual user guide does sometimes-- which is fully appreciated! there's many options that needs a little extra defining imo..


it's the space between the details where we sometimes miss the clarities..plz+ty.

[Xenakios]

Originally Posted by Bri1

hmm-this seems a contradiction-when clearly it does alter the sound in other reaplugs--no? they are not convolving though_eh?

Like I already wrote above, convolution done with the aid of FFT is a special algorithm that doesn't work like most other FFT processing algorithms work, where the FFT size has a huge impact on the sound.

And no, convolution is not the only spectral processing algorithm, it's useful only for applying impulse responses into sounds. (It's not even really a spectral processing algorithm as such because the same results could be achieved in the time domain, it's just dramatically slower to calculate that way.) Spectral EQ, pitch shift, time stretch, even spectral visualizers and so on, use completely different algorithms where the FFT size, the amount of window overlaps and the used windowing shape affect the sound (or analysis results) a lot.

[Bri1]

each new thought counts-! really just extra glad people are thinking..more!
cheerz.

[mschnell]

Originally Posted by Justin

Correct. The parameters for FFT size and ZL etc *only* affect PDC and performance characteristics— the resulting audio will be exactly the same.

(Obvious for "ZL".)

OK, As you both state this it's necessarily correct regarding FFT-size. Seemingly it does not do "convolution in overlapping chunks" (AKA "FIR") (as the basic FFT does), but something resulting in the same output as a straight forward convolution would do ("IIR").

I did a "spectral subtract" JSFX (Crosstalk canceller), that works really nice and with this the "lowest frequency by FFT size is as well theoretically as practically obvious.

So I need to null over why exactly this is different with convolution....

Thanks for education...
-Michael

[mschnell]

Originally Posted by Justin

Correct. The parameters for FFT size and ZL etc *only* affect PDC and performance characteristics— the resulting audio will be exactly the same.

I see:
- the bigger the FFT size the greater the PDC and the lower the CPU demand
- the smaller the FFT size the smaller the PDC and the higher the CPU demand
- "ZL" set : PDC = 0, high CPU Demand.

So why can the FFT size be selected with "ZL" set ?

And what exactly is "LL" ?

-Michael

[Justin]

Originally Posted by mschnell

So why can the FFT size be selected with "ZL" set ?

And what exactly is "LL" ?

If ZL is set, then it uses a system where it uses a FIR for the lowest latency part of the impulse, then smaller FFTs for medium, and large FFTs for the longer latency stuff. If you use a smaller FFT size in ZL mode, it will increase the overall CPU use but make the CPU use more consistently spread across blocks.

If LL mode is set, it offloads work to another thread, allowing lower CPU use and less a more consistent spread of CPU across blocks.

[mschnell]

OK, Great stuff !
Seemingly the FFT size setting is obsolete with "ZL" being set.

And the name "LL" ("low latency" ???) seems like completely misleading.

Anyway, I had been right switching on as well "ZL" as "LL" for my Live setup .

Thanks again,
-Michael