"Freeverb" port...

[Shifrin]

http://www.kvr-vst.com/resources/pluginsrc/freeverb_src.zip

Hahahahahahahahah
See you cant always trust searches

Thanking you! Will compare it to what I already have, just for any inconsistencies

Shif.

[ik_ik_ik]

Only thing left to do might be to add some denormal checking in the feedback paths of the filters.

Shif,

I had a look at your Freeverb port today. It's really interesting and educational to see the guts of something like that Amazing layout as always too!

Something came up whilst I was trying it out...

Fire a click into the reverb, sounds great Then, leave it and the CPU hits the roof after about 30 seconds (on my Centrino 1.6GHz at full throttle). If I fire some more clicks into the reverb then things seem to recover. Seems to be repeatable and doesn't seem to depend too much on the reverb parameters so I'm wondering if this might this be related to the denormal checking you mentioned?

Cheers,

Inigo

[Shifrin]

Actually I think I had a similar thing happen with the CPU jumping and forgot to mention it here!!!

I don't think there should be denormal problems as the schematic gets compiled to SSE code?!

Maybe jorge could offer some info/advice!

Shif.

[jorge]

Actually I think I had a similar thing happen with the CPU jumping and forgot to mention it here!!!

I don't think there should be denormal problems as the schematic gets compiled to SSE code?!

Maybe jorge could offer some info/advice!

Shif.

Denormals are not related to SSE but to the CPU. I think P4 and Celeron have a problem with denormals while Pentium M doesnt. I´m not sure about Athlon but I think it is a lot better than P4 and Celeron.

The problem described above sounds like a tipical Denormal problem as the values recirculating around a feedback path keep getting smaller until they´re treated as denormals which I´m guessing is after the 30 sec.

Getting rid of denormals is something that should be done in the schematic itself. One way is to add and subtract 1e-18 in the feedback path.

[ik_ik_ik]

Denormals are not related to SSE but to the CPU. I think P4 and Celeron have a problem with denormals while Pentium M doesnt. I´m not sure about Athlon but I think it is a lot better than P4 and Celeron.

The problem described above sounds like a tipical Denormal problem as the values recirculating around a feedback path keep getting smaller until they´re treated as denormals which I´m guessing is after the 30 sec.

Getting rid of denormals is something that should be done in the schematic itself. One way is to add and subtract 1e-18 in the feedback path.

If I remember right Jorge (from the good old runaway CPU topic) we both use Pentium-M (Centrino) machines - maybe they do have problems still (there's the usual sea of anecdote on the web)?

This was an interesting article I ended up reading after the 1e-18 suggestion. I tried the add subtract trick in the feedback paths in both the "comb" and "allpass" sections but SM went into a spate of crashing out :-( Probably my error as I'm tired; I'll have another look tomorrow...

Inigo

[Shifrin]

I'll have a look at the denormal issue, funny thing is I run an Athlon XP and have had no problems with denormals before, even with VST/i's that are known to give bad denormals on P4 processors.

Shif.

[ik_ik_ik]

I've fiddled about with the comb modules but no luck so far. I'm pretty sure the problem is there rather than the allpass filter chains since isolating the combs gets rid of the problem.

I noticed yesterday that the problem seems worse when very short impulses are fired in to the reverb, less so with longer sounds. It could be a property if not weakness of the actual algorithm.

Jorge, SM crashed out when connecting an empty float to the damping input of the Freeverb module (whilst it was running). I'll email you the dmp.

Inigo

[jorge]

Jorge, SM crashed out when connecting an empty float to the damping input of the Freeverb module (whilst it was running). I'll email you the dmp.

Thanks Inigo. Much more useful than the dmp is the schematic itself so we can recreate it. I'm assuming it´s the one posted on this thread.

[ik_ik_ik]

Jorge, SM crashed out when connecting an empty float to the damping input of the Freeverb module (whilst it was running). I'll email you the dmp.

Thanks Inigo. Much more useful than the dmp is the schematic itself so we can recreate it. I'm assuming it´s the one posted on this thread.

Yep. That's the one (as found in sk0re's NO_Effects pack).

[Shifrin]

I've fiddled about with the comb modules but no luck so far. I'm pretty sure the problem is there rather than the allpass filter chains since isolating the combs gets rid of the problem.

I've not had much free time to look at this recently, but there must be a way to fix it I'll have a look at the comb sections too, assuming I don't get crashes all the time

Shif.

[oddson]

Anyone interested in this project might want to have a look at this bug report.

I've fiddled about with the comb modules but no luck so far. I'm pretty sure the problem is there rather than the allpass filter chains since isolating the combs gets rid of the problem.

Both the combs and allpass have mono feeds adding at the input of a delay - which appears to be problematic.

[oddson]

This is primarily for sambean... but if anyone else knows please feel free...

I'm looking at your impulse graph in the bug thread, I'm not sure why the "correct" impulse chart is the one you've indicated, other than it matches what the literature says is correct.

It seems to me the time-zero spike should be negative as the only path that doesn't go through the delay is being multiplied by the inverse gain param (through the so called feed forward path).

Any chance of my second free DSP lesson?

Oh yeah, the freeverb port sounds better (i.e. less 'metalic') with the explicit add components. (But I haven't done any systematic check against alternatives.)

Also: If Jorge's diagnosis about the stage addition is correct then shouldn't the explicit add version be correct.

And: What does it mean that poles show negative and positive at what appears to be the same time on the 'incorrect' impulse charts.

And: Can you shed any light on the crazy FFT charts in my post?

Ever greedy for answers!

[skOre]

Sometimes, the correct things sound worse than broken stuff...

[sambean]

I'll try to explain what I can as best I can.. .. But if anyone else can put their 2p worth in please do..

I modified the layout slightly from how Shif had designed it to match the diagram I showed of the allpass filters where the the feedback input is equal to g ..


In this layout the feedback path is multiplied by the inverse (-g), and the feedforward by (g), thats why the first spike is positive.. (1 * g)

We have to wait for this impulse to pass through the delay , it then comes out the delay (delay out = DOut = 1), through the feedback loop (DOut * -g), and through the feedforward loop again (DOut * -g * g)

At this point we have:

Output = delay out + feedforward loop
= Dout + Dout * -g * g
= Dout (1 - g^2)

New Delay input = DOut * -g (from feedback loop)

as the new delay input = delay output * -g this implies the next spike will be negative and each consecutive spike will alternate between positive and nagative.. And also as g < 1 and (1-g^2) <1 each consecutive spike will be smaller in amplitude.

So for the impulse response we have

g, (1- g^2), -g(1- g^2), g^2(1 - g^2)...

for g = 0.7

0.7, 0.51, -0.357, 0.2499,... which is what we see for the impulse response..

[sambean]

Just found this.. Which shows you can have the inverse g on the feedforward and the positive g on the feedback..

http://www.harmony-central.com/Effects/ ... lpass.html

For the 'incorrect' resposes seen in the other thread (positive and negative spikes at the same time) what I think is happening is the output is being calculated from the delay output and the feedforward loop then the feedback loop is is being calculated. so on the following sample we have the impulse being spread over 2 samples, one positive one negative..

As to why the allpass (should) have a flat response consider the feedback and feedforward sections separately (set the value for the other =0)- the feedback section's frequency response is that of an upward comb filter and the feedforward section has a downward comb filter, add them together and they cancel each other out, leaving a flat frequency response..


What you were seeing in your frequency response of the files you posted was some kind of strange comb filter (hence metallic sound?).. Have a look at the frequency response with the other FFT (non-logarithmic)