Reverb Subculture

[Casey]

OK, I just saw your additional note.

I thought you had multi tap delay lines feeding back. If you simply have multiple delays feeding back, then you view the topology as an FDN with a specific feedback matrix. The gains in this matrix must be arranged such that the power within the structure is conserved. (As you have noted!)



-Casey

[seancostello]

Originally Posted by chrisj

*edit* Did some googling- it is a Schroeder model with global feedback over the entire thing in small amounts. It looks like a Householder arrangement but instead of -2/N combs, it's a very small positive feedback. I'm sorry, I'm posting too long again :(

This will blowed up good! Blowed up REAL good!

YouTube - SCTV 4 Farm Film Report

In reverb terms, "blowed up" is used to refer to the instability that happens when you have a feedback gain of greater than 0 dB for some frequency. The amplitude of the output will keep increasing. With fixed point systems that use saturation, you can end up getting a stable oscillation. In floating point systems, it will eventually go outside of the floating point numerical range, and you will get NaNs, which are evil.

Read this whole chapter to learn how to work with feedback around parallel delay lines:

Time shifts and delays

Miller Puckette was one of the pioneers of feedback delay networks. Michael Gerzon developed the theory about 13 years before Puckette published his findings, but I don't know how many people actually read Gerzon's papers - they were in a journal that was very rare within the US.

[seancostello]

Originally Posted by Casey

Hmmm, not sure I see what you mean.

An allpass filter does not have a metallic ring, it is allpass. Allpass filters can lead to a metallic sound because of their regular spectral smear. At the same gain, smaller allpass filters will have less spectral smear, and will cause less of a metallic residue in the tail.

Allpass is allpass, but this doesn't mean that all of the poles are the same distance from the unit circle. If you have a few poles that are closer to the unit circle than others, it seems like these will ring out longer than the others in the decay. Put feedback around these allpasses, and the poles will get even closer to the unit circle.

As far as allpass filters not having a metallic ring, try creating an allpass delay nested 10 deep, with all the allpass coefficients at 0.7, and total delay at 20 msec, and run an impulse through it. This is an allpass system, but its decay is perceived as VERY metallic.

We may be arguing about semantics here. You say spectral smear, I say ringing poles. The point is that nested allpass filters are tricky to work with.

[j_j]

I've had good luck working up a bit of an I/O framework (digital or analog) and then just using a netbook and gcc on linux. You'd be surprised what a dual-core atom will do

And your hardware is already built.

[dale116dot7]

Originally Posted by j_j

I've had good luck working up a bit of an I/O framework (digital or analog) and then just using a netbook and gcc on linux. You'd be surprised what a dual-core atom will do And your hardware is already built.

A netbook is not a 1U high 19" rack like most pieces of outboard gear. I realize that may not be an issue for everybody, but for some people it is. Also, I rather enjoy designing the hardware... bring on the soldering iron.

[j_j]

Originally Posted by dale116dot7

A netbook is not a 1U high 19" rack like most pieces of outboard gear. I realize that may not be an issue for everybody, but for some people it is. Also, I rather enjoy designing the hardware... bring on the soldering iron.

Hm.

I could set this on on a 1U rack shelf.

Seriously, it would work, but if you want to build, that's cool. I'm just tired of DSP's and the notoriously annoying compiler/assemblers that they come with. Been there, done that, and for way, way too (unblievably gross and offensive string of expletives) long.

First DSP I used kinda had a symbolic assembler. 4 tab fields, one for each stage of the pipeline. data moved from right (far tab) to left (near tab) as it got fetched, operated on once, added or not, and hten saved.

Branching was, well, possible. Barely.

[dale116dot7]

Originally Posted by j_j

I could set this on on a 1U rack shelf. Seriously, it would work, but if you want to build, that's cool. I'm just tired of DSP's and the notoriously annoying compiler/assemblers that they come with.

Actually, an 'industrial' computer - something like a PC104 or something like that - with the same dual-core processor, also running Linux but in a 19" 1U box would be interesting. You could easily do your development on a netbook or whatever, and have two UI front-ends, one for a PC environment, the other for a little LCD and a few rotary encoders. Use a 'flash' hard drive in the 19" box to get rid of moving parts, that might work.

I don't mind working with the DSP56k family even in assembly code, it's relatively easy to write - almost as if I were programming on a PDP11 or 68k or some other CISC microprocessor. VLIW assembly code looks scary to me, though.

[Casey]

Originally Posted by seancostello

We may be arguing about semantics here. You say spectral smear, I say ringing poles. The point is that nested allpass filters are tricky to work with.

Yes you are right, we are talking about the same thing.



-Casey

[seancostello]

Originally Posted by j_j

I've had good luck working up a bit of an I/O framework (digital or analog) and then just using a netbook and gcc on linux. You'd be surprised what a dual-core atom will do

Do tell. What can it do?

This is an interesting idea, especially if you are running Linux in a rack box (or smaller, if you use a mini-ITX, nano-ITX, or pico-ITX format). I haven't tried an Atom, though, so I don't know how they compare with the standard Core2Duo processors, or whatever they are called for PCs. Does the Atom have SSE instructions?

It probably wouldn't be that useful for stomp pedals, as I presume that an Atom is much less cost effective than something like the FV-1 or a Blackfin. However, I know that you can compile VST plugins for Linux. Hmmm.

[dale116dot7]

Originally Posted by seancostello

It probably wouldn't be that useful for stomp pedals, as I presume that an Atom is much less cost effective than something like the FV-1 or a Blackfin. However, I know that you can compile VST plugins for Linux. Hmmm.

That's almost always the case - for a stompbox, one other biggie is power consumption. A PC chipset of any kind sucks back the juice. It is true that a netbook takes less power from the wall than a 480L or 224, but a reverb based on something like the AL3201 in a stompbox (which will out-compute the 224) can be designed to take maybe 20mA from a battery using a linear regulator (10mA for the 3201, and about the same for the ADC-DAC), and if you spring for the cost of a switching power supply (all of three or four parts) you can get it down to probably about 7mA from a 9V battery - about 80 hours of use. On the other hand, my Aspire One netbook sucks about two amps out of its battery, and would attempt to drain a 9V stompbox battery in about ten minutes - if you could get the current out of a 9V battery fast enough.

[Froombosch]

Maybe already been discussed:

Is the phaseresponse considered more important then the amplitude response within high order interpolators?


Harrie

[seancostello]

Originally Posted by Froombosch

Maybe already been discussed:

Is the phaseresponse considered more important then the amplitude response within high order interpolators?

Not for reverbs, IMO. Reverbs scramble phase anyway, so the phase response is not that important. The things I consider important are the amplitude response, and the SNR when the delay length changes by more than 1 sample:

- Linear interpolation has poor amplitude response versus frequency, but a nice SNR with wide modulation widths.
- Higher order FIR interpolation schemes have better amplitude responses, but the cost goes up with the order.
- Some allpass interpolation schemes can be very noisy when the modulation width is fairly high, so you have to be careful. This is due to the allpass coefficient getting too close to the unit circle, which results in a transient that takes a while to ring out.
- Using no interpolation results in a perfectly flat amplitude response, but crappy SNR.
- If your modulation is updated at a slower rate, this increases the SNR as well.

[Casey]

I look for opportunities to combine linear interpolation when I have already upsampled significantly for other reasons. Sort of a freebie.

In some cases multiple high order interpolations are more expensive than just running your alg at a high sample rate all the time and using linear interpolation, watch for that.



-Casey

[seancostello]

Originally Posted by Casey

I look for opportunities to combine linear interpolation when I have already upsampled significantly for other reasons. Sort of a freebie.

In some cases multiple high order interpolations are more expensive than just running your alg at a high sample rate all the time and using linear interpolation, watch for that.

You mentioned this earlier, but it is worth mentioning again. This has shaped plans of mine for a future algorithm...

[chrisj]

Originally Posted by seancostello

This will blowed up good! Blowed up REAL good!

Sure will thanks, guys- I was able to do some tweaking. With your help I got it to this... I would still like to compare more directly to existing work. This is from Casey's guitar example which I like. Again, are there dry samples I should be using to post with?

[Casey]

Originally Posted by chrisj

Sure will thanks, guys- I was able to do some tweaking. With your help I got it to this...

Very nice Chris. I particularly like the short example. The long example has a bit too much allpass going on though really, just try to settle them down.



-Casey

[chrisj]

You mean more in this direction? There's a damping slider, first example was 0.5 and 0.5 dry/wet on both. This one is damping to 1.0.

It's tricky because FarSpace is the one I wanted to be ridiculous infinite-space verb- NearSpace is more contained. I'd like to lean in the direction of the spaciousness and invisibility of your reverbs, and hopefully it's a tip of the hat- even though I'm not using any of your techniques that I know of- intentionally avoided similar verb structures. I'm trying to do my own thing, it just needs to have some similar qualities to the goodness of your verbs

[Froombosch]

chris,

I would rather try something different as a source to listen to a laaaaaarge reverb.


Harrie

[dale116dot7]

I've been working on a revised hardware platform, I had too many blue jumper wires on the previous version, and after too much handling, it's starting to get a bit flakey. Also, a double-sided PC board isn't the best for a 100 MHz data bus - so a 4-layer it is. Along with fixing things that were obvious errors on the previous PC board, I've changed the DSP from a 100 MHz DSP56366 to a 200 MHz dual-core DSP56720. I'm thinking about using SDRAM, however, I'm a bit confused as to the best way to arrange data and move it to/from the SDRAM. It seems to me that SDRAM timing is pretty slow for hopping around in memory. For long delays, it's pretty obvious what to do (put the head and tail in internal SRAM and burst the middle into and out of the SDRAM) but for a high density multitap algorithm, the answer isn't quite so simple. Is this a case where certain algorithms just don't run as efficiently on different hardware? Is it best to try to keep large tap sizes in internal RAM if I can? Would I be better off with an untapped algorithm like an FDN? A single random SDRAM access takes about the same amount of time as almost 20 instructions (per core) - if in internal SRAM, I could do four allpasses (two per core) in the time it takes to just fetch a single sample from the SDRAM.

[Warp69]

Originally Posted by dale116dot7

Is it best to try to keep large tap sizes in internal RAM if I can? Would I be better off with an untapped algorithm like an FDN?

Is FDN an untapped algorithm?

[dale116dot7]

Each delay segment has a defined start and stop, without pseudo-randomly spaced taps in the middle like in the loop-style algorithms (Griesinger/Dattorro). The output comes from a summing matrix at the end of the delay lines. In this arrangement, you can easily move the middle section of each delay out into slow RAM, so long as you can write the head and and read the tail efficiently (fast RAM). That should be relatively cheap to do (in processor cycles), should be a relatively easy operation (you can probably program a DMA controller to do the memory moves), and also should handle resizing the delays quite easily. If a delay line is longer than about 100 samples, you can burst the data into and out of the SDRAM, and if it's shorter, you just turn off the SDRAM copy and leave the delay in SRAM.

Alternatively, if all of the audio for a reverb would fit in about 90k of SRAM, it could all sit in SRAM, and the SDRAM would only be used for bulk delays - predelay or slapback echo, that kind of thing. But if you upsample, then the 90k would disappear quickly - that would be under a second of audio at 96k.

[Warp69]

Originally Posted by dale116dot7

Each delay segment has a defined start and stop, without pseudo-randomly spaced taps in the middle like in the loop-style algorithms (Griesinger/Dattorro). The output comes from a summing matrix at the end of the delay lines.

You're correct, when we talk about a very basic implementation of FDN.

Btw. With the correct feedback matrix you can create 'loop-style algorithms' in FDN.

[dale116dot7]

Yes, it would be a sparse matrix. It may not be as 'efficient' to do it that way, but I'm looking at the hardware and trying to figure out the most efficient way of doing it - or deciding if I need to rework the processing hardware. The last thing you want to do is have a very beautiful PC board all put together, then find out the algorithms you want to run won't run efficiently on the hardware. An option I was thinking of was to put more than one DSP on there, but for a DIY project, multiprocessing seems a bit overkill.

What I found on the last design was:

• The DSP was adequate to do very complex loop-based reverbs
• Long loop times were not accomodated particularly well (special effects and sampling, not reverbs) - and there was a barrier at 256k samples because of the address line arrangement of the DSP56366.
• The SRAM performed adequately but did add a wait state for every access. More on-chip RAM (zero wait state) would be better.
• I did not have digital audio I/O or USB capabilities, and I wanted to add them - espeically the digital I/O.
• The host processor (MCF51AC256) was not really fast enough to do modulation, and the DSP was busy enough processing audio that I didn't want to burden it.
• The I2C interface to the front panel was ok but added too many chips to the front panel PC boards.
• Though the SRAM was nice, it also cost $50 for a measly 512k of it.
• The linear regulators were ugly so I'm moving to a switcher for the main PSU. The PC board now has extra ferrite filters to get rid of the hash, plus separate analogue and digital 3.3V regulators.

So I upgraded the host processor to a MCF52259, ran parallel I/O off of it to the display panel, upgraded the DSP to a DSP56720, added AES digital I/O, a USB connector, and added a ton of SDRAM. The problem with SDRAM is its random access time is sucky, but it's cheap, and it bursts really quickly. Everything else is a significant step upwards, except for memory access time, which is about a factor of 10 worse (for the first access) - then its on-par. I'm just finishing up the PC board in my CAD package now. But I want to make sure that the algorithms can run efficiently before I get the new boards made up. I picked the same families of processors so I can reuse most of the code, and all of the development tools.

[seancostello]

If you are working with SDRAM, you might want to switch to block-based processing, instead of sample-by-sample. My guess is that the set up and take down time of the SDRAM access is what takes the bulk of the cycles, and that once you have your setup done you can grab a block of samples rather quickly. From reading between the lines of what NS has posted, the PCM96 uses blocks of 32 samples. Back when I worked with ADI, I regularly used blocks of 16 or 32 samples to write reverbs, and it can work very well. You can do allpass loops this way, FDNs, whatever.

[chrisj]

Originally Posted by Froombosch

chris,
I would rather try something different as a source to listen to a laaaaaarge reverb.
Harrie

You mean like this? This is why I was asking if there were dry samples I could use. I feel okay posting it in this thread for feedback, but I don't feel I can show these clips outside the thread because they're Casey's samples.

It's not a huge deal, I do make demos available, but I wish there were great public domain audio clips as good as this.

I think the orchestral sample likes the laaaaaaarge reverb better- and you get more of a sense of the bass of the hall, which is kind of tricky to do without a separate LFE reverb. This is more of what the big one is for.

[Froombosch]

Sounds nice to me. I tend to use snare/ spikey kind of sounds, so I can hear how the tail moves/evolves. In crowded music it is more about the first 200 ms or so. The rest gets masked.

[Froombosch]

Originally Posted by seancostello

Not for reverbs, IMO. Reverbs scramble phase anyway, so the phase response is not that important. The things I consider important are the amplitude response, and the SNR when the delay length changes by more than 1 sample:

- Linear interpolation has poor amplitude response versus frequency, but a nice SNR with wide modulation widths.
- Higher order FIR interpolation schemes have better amplitude responses, but the cost goes up with the order.
- Some allpass interpolation schemes can be very noisy when the modulation width is fairly high, so you have to be careful. This is due to the allpass coefficient getting too close to the unit circle, which results in a transient that takes a while to ring out.
- Using no interpolation results in a perfectly flat amplitude response, but crappy SNR.
- If your modulation is updated at a slower rate, this increases the SNR as well.

Thank you and Casey for your responces . Food for thought.

[Casey]

Originally Posted by chrisj

because they're Casey's samples.

I would have to look back, but I seem to recall that Rob King donated that sample.



-Casey

[Casey]

Originally Posted by seancostello

If you are working with SDRAM, you might want to switch to block-based processing, instead of sample-by-sample.

Of course you must still deal with samples on delay line input/output since any reverb would sound quite bad if limited to 16 or 32 sample boundaries.



-Casey

[seancostello]

Originally Posted by Casey

Of course you must still deal with samples on delay line input/output since any reverb would sound quite bad if limited to 16 or 32 sample boundaries.

No problem - just make sure that you adjust your delay lengths to take into account the block delay in the feedback path. For example, if you want a 1000 sample comb filter, and your block size is 32 samples, you would use a delay of (1000-32)=968 samples.