Login / Register
 
Reverb Subculture
New Reply
Subscribe
dale116dot7
Thread Starter
#1
8th April 2009
Old 8th April 2009
  #1
Lives for gear
 
Joined: Dec 2003
Location: Calgary, Alberta
Posts: 1,127

Thread Starter
dale116dot7 is offline
Reverb Subculture

Reverbs and other DSP stuff.... moved?

The thread on high-end was very interesting but probably should be here....

To answer an earlier question about SDRAM... I (and most DIY DSP'ers) are often 'stuck with' some sort of DSP that might not be ideal. I picked the Freescale DSP's because of the development tool costs of the TI and ADI parts. I'm sorry but a DIY'er can't justify several thousand dollars for a functioning development suite, and we normally can't finish a project in the 30-day eval period. So that limits the part choices quite a bit. Also, VLIW architectures do not lend themselves to assembly coding without the optimizers and schedulers. So what DSP to do a DIY 'verb with?

My first choice (not the best choice - but perhaps the simplest choice) was the Wavefront AL3201 - a picoverb on a chip. But you can code a lot of allpasses, if you want fifty allpasses in sequence, that's not a problem. It's a bit short on memory - only 32k samples. But it was a simple chip to learn about reverbs and other effects on.

My next choice was the DSP56366 which seems pretty good, and development tools (gcc) are free. I just use the assembler portion of it. But that DSP supports EDO DRAM but not SDRAM. Then I started looking at SDRAM controllers, and that opened up a can of worms - you can't just buy an SDRAM controller. You can, however, get a SDRAM controller IP core for an FPGA.

I don't like the overhead of round-robin delay lines - it's an extra few clock cycles per allpass or delay. Maybe I could build the round-robin delay lines into the FPGA with the SDRAM controller as well. Well, now that I've committed to put on an FPGA and incorporate an address generation unit, why don't I just build a effects-oriented DSP on an FPGA? I don't need that many instructions, how hard could it be?
#2
8th April 2009
Old 8th April 2009
  #2
Lives for gear
 
Casey's Avatar
 
Joined: May 2003
Location: Cambridge MA USA
Posts: 1,268

Casey is offline
Very nice, thanks for starting this thread!

Dale, I think you are on the money with FPGAs. I think that is the future of DSP, and a great choice for DIY. But today AD DSP still has a significant edge in cost per internal memory and computational performance. Then you have to also consider the awesome power of an Intel processor.

So, I think there are many implementation strategies that are going to appeal to different folks in different situations. It might be interesting to abstract out specific implementations initially and take a look at the basic reverb building blocks. Move on to overall reverb structures, and then see how they might map onto specific implementation strategies. What do you think?



-Casey
__________________
www.bricasti.com

My love shall hear the music of my hounds. - Shakespeare
dale116dot7
Thread Starter
#3
8th April 2009
Old 8th April 2009
  #3
Lives for gear
 
Joined: Dec 2003
Location: Calgary, Alberta
Posts: 1,127

Thread Starter
dale116dot7 is offline
Quote:
Originally Posted by Casey View Post
Dale, I think you are on the money with FPGAs. I think that is the future of DSP, and a great choice for DIY. But today AD DSP still has a significant edge in cost per internal memory and computational performance. Then you have to also consider the awesome power of an Intel processor.

So, I think there are many implementation strategies that are going to appeal to different folks in different situations. It might be interesting to abstract out specific implementations initially and take a look at the basic reverb building blocks. Move on to overall reverb structures, and then see how they might map onto specific implementation strategies. What do you think?
Here's what I've been thinking:

A lot of building blocks of reverbs are pretty hush-hush, and for good reason. Some are relatively public - Schroeder, Jot, Gerzon, Gardner. A common trend seems to be needing allpasses, combs, and relatively low-Q filters (6dB). And a delay line is pretty much used for all of them, though a filter only needs a single delay and could be done outside of a delay line structure.

Since I've worked with the AL3201, and since I've also repaired PCM70's and 60's and even a couple of newer units, I have a pretty good idea how the memory management works there - identical to the AL3201. So why not make the DSP just have a sample counter that decrements once each sample and add that to the offset? An adder in an FPGA is pretty quick. I need to present an address to the adder, and it does the delay line roundabout for me. I would need to have a separate path available to do chorus functions for other effects - and to break up modes in some of the allpass loops.

The second thing is what kind of memory. I like SRAM, but SDRAM is cheaper for the same amount of memory - by far. Looking at SDRAM, interleaving would be nice. If the design has started by being a super AL3201, doing four parallel threads would be good. That means that I need to have at least four accumulators. The RAM timing looks good for interleaving, I can keep the data bus at 100% for SDR SDRAM. But I need four threads and four accumulators.

At some point you need to pick the part. So I looked at the Xilinx Spartan-3E. It has fixed dual-port RAM blocks (good to store the program, and also for a register file), and also 18x18 signed multipliers - a few of them. Excellent. A rough drawing of a data flow diagram and distribution of the multipliers indicates that an allpass can be done in two cycles:

r0 += k1 * (r1 = mem<tail>)
mem<head> = r0 ; r1 = -k * r0

Similarly, a one-cycle low-pass filter would be trivial:
r3 = k1 * mem<input> + (1-k1) * r3

One more line makes a high-pass. With a 256-sample register file, that's a lot of filters.

And a multitapped delay is obvious...

mem<head> = r0
r1 = k1 * mem<addr1>
r1 += k2 * mem<addr2>
r1 += k3 * mem<addr3>
io<dacl> = r1

That looks good. To generate the chorus waveforms, another ALU could be used, or since the chorus waveforms are pretty slow-changing, a soft processor can be put on the FPGA to do it - there are some 32-bit ones, and a couple of 8-bits. There's an 8051 and a Z80 for the 8-bit ones. I like the Z80 since the last job I worked at used them for just about everything (actually, the Z80181). But the 8051 isn't too bad either. It just has to generate some LFO coefficients so it'll be loafing, anyways. Probably I'll pick the one that takes fewer gates.

Anyways, that was my line of thinking. I would have liked the AL3201 chip better if it had two serial audio ports and double the RAM. Then I would just build an array of them. This seems pretty good to me - a familiar design method (sample-by-sample), an architecture that is already familiar to me (the AL3201), a fair bit of performance (around 40 MIPS with 8-bit SDRAM, 80 with 16-bit SDRAM), and an effects-centred instruction set. The cost should be pretty low - around $20 for the FPGA plus SDRAM in single-piece quantities.

I know of one other company that has done DSP with an FPGA. International Rectifier did a control chip for motor drives that was originally an FPGA then was changed to a hard-programmed gate array later in the development. It's a nice part - does all of the PID's and PWM's and encoder interfaces that you need to build a variable frequency drive... IRMCK301/303.

-Dale
#4
8th April 2009
Old 8th April 2009
  #4
Gear nut
 
audioawake's Avatar
 
Joined: Jun 2007
Location: Europe
Posts: 96

Send a message via Skype™ to audioawake
audioawake is offline
Wow that's a great thread thumbsup
I have one question, that google couldn't answer:
what would be algorithmic interpretation of all-pass filter?
I mean y[k]=x*....

And another one is how to interpret those z-1 in filter transfer functions?

I'm a newbie so I'm sorry if it's a stupid question.
Thanks in advance
dale116dot7
Thread Starter
#5
8th April 2009
Old 8th April 2009
  #5
Lives for gear
 
Joined: Dec 2003
Location: Calgary, Alberta
Posts: 1,127

Thread Starter
dale116dot7 is offline
In a sample-by-sample processor, probably it is most efficient to be implemented as a lattice structure:

Harmony Central - Digital Allpass Filter

I can't speak for any professional reverb implementer, but after spending a bunch of time with the block diagrams of the Schroeder reverberators and my 'DSP for Dummies book' and the AL3201 programmer's guide, the lattice seems to be the easiest way to do it. In AL3201 assembler, it looks like this:

MEM diff 48
RAPB diff' k=-0.726
WBP diff k=0.726

and takes two clock cycles (or 325 nanoseconds).

The first instruction reads the end of the delay line, stores that value in B (a temporary register), and also takes that value times -0.726 and adds it to the accumulator. Note that the accumulator holds the input.

The second instruction stores the result from the previous multiply into the start of the allpass delay line, and takes the output of the delay line (that was in the B register), and adds the result of the first instruction times 0.726 to that, and the output is now in the accumulator.

If you are cascading allpasses, then you do this:

MEM diff1 48
MEM diff2 109
RAPB diff1' k=-0.726
WBP diff1 k=0.726
RAPB diff2' k=-0.726
WBP diff2 k=0.726

And if you want a time delay in between, you can do this:
MEM diff1 48
MEM diff2 109
MEM dly1 960

RZP ADCL k=0.5 ' read input registers
RZP ADCR k=0.5
RAPB diff1' k=-0.726
WBP diff1 k=0.726
WZP dly1
RZPB dly1'
RBPB diff2' k=-0.726
WBP diff2 k=0.726

and then to mix in a little of in between the allpasses into the output you can add to the end:
RAP dly1" k=-0.15
WAP DACL k=0 ' write to output

This line takes the halfway point between the two allpasses and adds it to the output of the allpass - then sends it to the D-A converter. In terms of a simple reverberator, what this does is take the first early reflections (allpass 1), runs that through a predelay (dly1), then the later reverberator (allpass 2), and sum a bit of the earlier reflections to the output of the second allpass. This reverb will sound awful, but you get the idea. You need to add some filtering... a first-order lag filter after an allpass will look like this:

RBPB diff3' k=-0.726
WBP diff3 k=0.726
WAP dummy k=0.750
RAP dly3+1 k=0.250
WAP dly3 k=0

You can have fun cascading and summing allpasses, filters, combs (which are an allpass with not identical coefficients), delays, and multiple delay taps. Most of the time you get something that sounds awful (except maybe for a sci-fi special effect), but sometimes you get something useful. You can implement a Schroeder reverb quite easily. Although it doesn't sound excellent, it does sound ok. Adding more stages can smooth it out.

Sometimes a creation you make sounds awful but if you know where it rings, you can add a chorus to that allpass to break that up, or you can retune the delay line lengths to move the ringing where it is pretty even. Doing reverb development this way (what I call the 'crash and burn' software development method) is time consuming. It would be far better to implement the algorithm using 'C' or Java or Fortran or something like that, listen to it on a PC, then once it's working, write it for the DSP you're using.

Even though allpasses are nominally flat, they still can 'ring' since in a reverberator, allpasses are usually relatively long and on an impulse you can hear ringing as 'bunching' of the impulses when you look at it in the time domain. If it 'bunches' on an impulse, it will ring when you put audio through it. Another bad artifact is 'repetition' - where you hear a repeating 'tape loop' pattern in the reverb tail. From what I can tell, it means that you have too much long allpass and not enough short allpass.

An interesting thing about the lattice implementation of an allpass is that the audio signal within the allpass is useable, too, where in the middle of a comb filter or probably another allpass implementation it may not be.

A 'z' is a unit delay, if I run the AL3201 at its nominal design frequency (48 kHz sample rate), then a z-1 is 20.8 microseconds, or z-48 is one millisecond. I've occasionally seen the delays specified in milliseconds, too.

The 'crash and burn' software method is an oldie but a goodie. You try running your box (whether it's a reverb or a mobile data terminal or whatever), and when it crashes, you pull out the EPROM chip and burn another one. I'm sure the reverb developers here have been through it. I picked the AL3201 to show the code since it is a very reverb-centered instruction set and it is pretty easy to understand how it works.

Now, Casey will probably correct me on a bunch of points, but that's what I've learned so far.
#6
8th April 2009
Old 8th April 2009
  #6
Lives for gear
 
Casey's Avatar
 
Joined: May 2003
Location: Cambridge MA USA
Posts: 1,268

Casey is offline
Great stuff Dale.

Could I talk you into using easier to read notation? I'm not familiar with the part you are using or the assembler instructions. But hey, no complaints, you are really laying a lot out there!

One point on allpasses that I'm sure you are aware of, but is worth mentioning, is their behavior when looking at group delay (or phase) vs. frequency.

Because an allpass filter will delay some frequencies more than others, the frequencies which are delayed longer stick around until the end of the tail, while the other frequencies that are delayed for a shorter time through the allpass fade out before the tail has completed.

This is particularly true when the same signal is passed over and over again through the same allpass, (like in a loop!), because the delayed frequencies compound over time.

What this sounds like is a "metalic" finish to the tail.

The best way to hear this is to excite the entire loop with white noise (all frequencies) then stop the white noise and listen to the tail. You will hear a strong correlation between the size and gain of the allpass filters and the amount and character of the metalic finish to the tail.

One word of warning. White noise is potent stuff, don't sit all day tweaking with white noise if you don't want to hear your ears ringing when you go to bed that night!



-Casey
#7
8th April 2009
Old 8th April 2009
  #7
Gear nut
 
audioawake's Avatar
 
Joined: Jun 2007
Location: Europe
Posts: 96

Send a message via Skype™ to audioawake
audioawake is offline
Thank you very much dale116dot7 !

Quote:
Originally Posted by Casey View Post

This is particularly true when the same signal is passed over and over again through the same allpass, (like in a loop!), because the delayed frequencies compound over time.




-Casey
How about a little randomization in filters phase response, if it's even possible with all-pass filters in general?
#8
8th April 2009
Old 8th April 2009
  #8
Lives for gear
 
Casey's Avatar
 
Joined: May 2003
Location: Cambridge MA USA
Posts: 1,268

Casey is offline
Quote:
Originally Posted by audioawake View Post
How about a little randomization in filters phase response, if it's even possible with all-pass filters in general?
Oh yes, certainly.



-Casey
dale116dot7
Thread Starter
#9
9th April 2009
Old 9th April 2009
  #9
Lives for gear
 
Joined: Dec 2003
Location: Calgary, Alberta
Posts: 1,127

Thread Starter
dale116dot7 is offline
I just cut+pasted from my source code. What the allpass is doing is (in 'C') is:

float diff1[48];
float input;
float output;
float k=0.725;

diff1[0] = input + k * diff1[47];
output = -k * diff1[0] + diff1[47];


Where diff1 is a simple delay line. Somewhere else is located essentially this:
for(c=47;c!=0;c--)
diff1[c]=diff1[c-1];

This would be inefficient. You just don't do a delay line by copying all of the data one spot over in memory. That is about as (in)efficient as convolution. It just demonstrates how it works.

If 'k' is set to zero, you get a simple delay line. If it's set at 1 or higher, you get an oscillator. Practically, values between 0.25 and 0.75 or maybe 0.85 are useful.

In practice you would do the delay by decrementing an address (in 'C' they call it a pointer, in a real language it's an address) every sample, if you're doing a sample-at-a-time algorithm. Some reverbs (the TC M5000, the K-T DN780, the Alesis units, and probably a lot more) do the sample shifting in hardware by messing with the address sent to memory.

For hardware archeologists, the K-T DN780 is actually a pretty good 'by the book' example of an older reverb-specific processor using no custom IC's (except for a couple of bipolar PROM's), and the service manual is available for examination of the DSP hardware. If you're looking, IC29-34, IC36, and IC38 on the DSP board form the address 'mangler'. IC36 and IC38 make up a 16-bit counter, the remainder of those chips are a 16-bit adder. If you're not a hardware geek, then don't worry about this. If you are a hardware geek either you already knew how it was done, or you do now.

-Dale
#10
9th April 2009
Old 9th April 2009
  #10
Lives for gear
 
Casey's Avatar
 
Joined: May 2003
Location: Cambridge MA USA
Posts: 1,268

Casey is offline
So Dale, thanks for converting to C! Much more clear.

Leaving allpass filters aside for a moment;

When looking at the entirety of an interesting reverb loop(s), it is important to identify which elements represent feed back paths and which elements represent feed forward paths.

Each path will have a specific frequency response, and a gain which will determine how close to being flat in the frequency domain the element is. Typically, flatter is better. Typically, frequency peaks that are fat and round will sound better than those which are more needle like.

This understanding can give some insight into the behavior of a reverb of any topology, increasing the predictive nature of the design process and reducing the required amount of trial and error.

Of course reverb topologies are defined by many characteristics, but the purposeful decisions made as to how feed back and feed forward paths are used is a good place to start any design from.



-Casey
dale116dot7
Thread Starter
#11
9th April 2009
Old 9th April 2009
  #11
Lives for gear
 
Joined: Dec 2003
Location: Calgary, Alberta
Posts: 1,127

Thread Starter
dale116dot7 is offline
I haven't really thought about that so much. But perhaps implementing an algorithm in C, then playing noise through it (input in a raw audio file format, same with output), then doing a spectrum or waterfall plot of that file - would that be a good approach?

And if there's a peak, can one put a 'snooper' to find the offending path? For example, write the 'output' audio files, but also a few files at selected points? I suppose once the algorithm is written and tested in C, it can be ported into a DSP box either by direct compiling, or hand compiling into assembler.

I just finished up a reverb algorithm (on the AL3201) that is just somewhere around 45 or so allpasses in series. It has a bit of a ring, and a very slow buildup. So I took taps from the first 20 allpasses using sloped tap coefficients with pseudo-random signs, and sum that to the output. That improved the buildup - without it the buildup is rather unnatural. The only thing is that it dies out unnaturally, so some feedback should help, but I've been afraid to try that due to ringing. It sounds kind of like a gated and inverse reverb combined, actually.
#12
9th April 2009
Old 9th April 2009
  #12
ValhallaDSP
 
seancostello's Avatar
 
Joined: Feb 2009
Location: Pacific NW
Posts: 2,566

seancostello is offline
Quote:
Originally Posted by Casey View Post
One point on allpasses that I'm sure you are aware of, but is worth mentioning, is their behavior when looking at group delay (or phase) vs. frequency.

Because an allpass filter will delay some frequencies more than others, the frequencies which are delayed longer stick around until the end of the tail, while the other frequencies that are delayed for a shorter time through the allpass fade out before the tail has completed.
Barry Blesser has a recent patent that addresses this issue. Blesser introduces a filter type called "notchpass," where the group delay peaks are matched to corresponding minimums in the frequency response. In the feedback loop of a comb filter, the result is a reduction or elimination of the metallic sounding frequencies sticking around.

I haven't tried this, as I first read about it in an issued patent, and it was not in any prior art that I know of. I tend to deal with these allpass issues by reducing the coefficients to lower levels, by randomizing things over time, or by not using allpasses.

Sean
#13
9th April 2009
Old 9th April 2009
  #13
ValhallaDSP
 
seancostello's Avatar
 
Joined: Feb 2009
Location: Pacific NW
Posts: 2,566

seancostello is offline
Quote:
Originally Posted by Casey View Post
Dale, I think you are on the money with FPGAs. I think that is the future of DSP, and a great choice for DIY. But today AD DSP still has a significant edge in cost per internal memory and computational performance. Then you have to also consider the awesome power of an Intel processor.
One possibility is using the Linux tools for the Blackfin DSP:

Blackfin Koop

Free compilers, instead of $4K. The development board is very low cost as well, and schematics are available for it. I am not sure how efficient the compiler is, but you might be able to rip some useful render loops out of the source code for VisualAudio:

VisualAudio® 2.6 Audio Software Development Tools and Libraries | Blackfin Processors | Embedded Processing and DSP | Analog Devices

The modules assume block based processing, which will work well with cache based systems and SDRAM access. It would obviously be a fair amount of work to extract the useful code, but easier than creating audio modules from scratch, especially since there is a fair amount of hand-tweaked inner loops in there.

Another possibility, which you had suggested, is to use an FPGA for your memory management, and have a DSP hook up to this. In such a situation, the FPGA would deal with grabbing groups of samples out of the SDRAM, as well as the circular buffering. I'm not that versed in FPGAs (or the hardware side of embedded designs, for that matter), so I don't know how this would work, but it is an idea to toss out there. I think that Al Clark of Danville Signal Processing has implemented such a SDRAM controller using an FPGA on one of his SHARC development boards.

Quote:
Originally Posted by dale116dot7
I just finished up a reverb algorithm (on the AL3201) that is just somewhere around 45 or so allpasses in series. It has a bit of a ring, and a very slow buildup.
I view this as the central limit theorem in action. If you have enough of any filtering block in series, the impulse response ends up looking like a Gaussian bell curve. This can be annoying or useful, depending on the application.

Quote:
Originally Posted by dale116dot7
So I took taps from the first 20 allpasses using sloped tap coefficients with pseudo-random signs, and sum that to the output. That improved the buildup - without it the buildup is rather unnatural.
About 9 years ago, my coworker and I were working on an implementation of the "Dattorro" reverb for a client. To save cycles, we ripped the taps out of the network, and just took the outputs from the existing delay lines. The result had very lumpy attack characteristics. My theory is that the output taps in allpass loop reverbs are used to eliminate the buildup issues that occur with a bunch of allpasses in series, as well as to add echo density during the attack phase.

A few of the older plugin reverbs (Silververb for Logic, some other reverb found in Arboretum's HyperPrism) consisted of a bunch of allpasses in a comb filter loop, with the output taken from the end. The resulting sound had a definite buildup in the attack.

Sean
#14
9th April 2009
Old 9th April 2009
  #14
Lives for gear
 
Casey's Avatar
 
Joined: May 2003
Location: Cambridge MA USA
Posts: 1,268

Casey is offline
OK, maybe this can be fun.

Let's build a simple little reverb from scratch, while thinking about some of the issues already mentioned.

Let's start with a modest 16k samples for our entire reverb section.

Divide those samples up into three unequal loops.

Three is nice because we can think of these loops as the 3 dimensions of a room and we can use a tool like this RealTraps - ModeCalc to look at how we might size the loops to achieve the flattest response (or fewest modes anyway).

Then just put an output tap in the middle of each loop (for now). And a gain element at the end of each loop to reduce the energy in the loops over time.

Send signal into the loops identically, and sum the 3 taps for the output.

OK so this is 3 feedback elements (the loops), and 3 feedforward elements (the tapped delay lines.)

This is just a start, it won't sound great but it gives a lot of material for gaining some inuition over the basic elements.

You will find that the sound is adjusted by changing the size of the loops and adjusting the gains at the end of the loops.



-Casey
dale116dot7
Thread Starter
#15
9th April 2009
Old 9th April 2009
  #15
Lives for gear
 
Joined: Dec 2003
Location: Calgary, Alberta
Posts: 1,127

Thread Starter
dale116dot7 is offline
Ok, I'll try that sometime this weekend. Just three recirculating delay lines, that's it? I would assume the 'golden ratio' should result in fewest modes, but maybe not? Treat the output as mono for now?

To test this, I'll be using my AL3201 box, I can add this new algorithm and the control knobs for each of the gains and sizes in about five minutes.

I was working up a delay line setting last night and put it in as a factory preset. It's titled 'Johnny'. One delay line, 142 milliseconds, a bit of rolloff, and a bit of feedback. I also managed to get a decent vocal plate setting. I think I tend to use too high of allpass coefficients, generally, as when I drop them down I get much less ringing, though I get a bit of a 'loopy' tail.
dale116dot7
Thread Starter
#16
10th April 2009
Old 10th April 2009
  #16
Lives for gear
 
Joined: Dec 2003
Location: Calgary, Alberta
Posts: 1,127

Thread Starter
dale116dot7 is offline
Here's what I came up with for observations:

At any delay less than about 50ms it sounds like a pitch. Above that it sounds like a tape loop. If I set one loop to about 100ms, another at 130ms, and another at about 160ms, the tape loops seem to be much less. But the other thing which was very noticeable was that even though the last delay loop would hide the tape loop effect anywhere from 140-195ms, the pitchiness of the noise (or snare drum) changed quite a lot. Around 160ms seemed to be pretty even, though I did not use a spectrum analyzer. With noise, the spectrum changes a lot. If I move the 160ms tap out to 180ms, the low end of the snare drum really pops out.

If I use something like a snare drum as opposed to a noise source as the input, the 'tape loop' sounds a lot like a helicopter. Adding a second loop at 130ms makes that sound totally go away and it sounds like a bad reverb. Adding 160ms sounds like a better bad reverb. Also, if you stop the sound, the tail of this (bad) reverb sounds pretty even - no particular 'ring' seems to stick out.

At feedbacks less than 0.5, it sounds like a couple of delay lines. At around 0.7 it starts to sound like there's a reasonable tail. Setting the levels at about the same volume level for each loop seemed to sound most natural to me.

What seems tricky here is getting a good frequency response (no peaks), and at the same time getting a good time response (nice reverb tail). One combination of delays seemed to work. Interestingly, those times didn't ratio very well. I got another reasonably nice sounding one at 50ms, 73ms, and 89ms, which have different ratios than the first set of numbers.

Setting one loop fairly short tends to make a 'tunnel' sound - very resonant.

Does this sound familiar?
#17
10th April 2009
Old 10th April 2009
  #17
Lives for gear
 
Casey's Avatar
 
Joined: May 2003
Location: Cambridge MA USA
Posts: 1,268

Casey is offline
OK, great!

All of your observations sound familiar.

So...

Now remove the single tap from each loop.

Stay with three loops.

Instead, place 3 taps on each loop. For now keep the gain of each tap the same.

Lets double our sample memory to 32k samples, to give some room for the additional taps.

Again using three taps allows the use of the modecalc tool to at least see what three taps looks like in a group.

Still feed all the loops identically (mono in), but now lets pick five taps to sum for the left and 4 taps to sum for the right.

The left and right channels should have at least one tap from each loop.

Now this is the first mention of psychoacoustics; the brain loves to hear a rocking back and forth of sound from the left then from the right then from the left...

So, while finding optimal tap positions on each loop, try to make sure that the taps chosen for the left and the right are interleaved in time (make the first left tap first overall) at least as far as you can, since this will be complicated by the loop sizes.

So now the possible adjustments include loop size, loop gain and now tap locations.

Still no good sound but more variables to contend with.



-Casey
#18
10th April 2009
Old 10th April 2009
  #18
ValhallaDSP
 
seancostello's Avatar
 
Joined: Feb 2009
Location: Pacific NW
Posts: 2,566

seancostello is offline
Quote:
Originally Posted by Casey View Post
Now this is the first mention of psychoacoustics; the brain loves to hear a rocking back and forth of sound from the left then from the right then from the left...
Any citations for this?

I'm curious to see where your tutorial leads...
#19
10th April 2009
Old 10th April 2009
  #19
Lives for gear
 
Casey's Avatar
 
Joined: May 2003
Location: Cambridge MA USA
Posts: 1,268

Casey is offline
David Griesinger mentions in a paper a left right rocking in the low frequencies as being optimal for generating a sense of space. The extrapolation to all frequencies is for ease of implementation for this case at hand.

Of course it could be right first, it's the rocking thats important.



-Casey
dale116dot7
Thread Starter
#20
10th April 2009
Old 10th April 2009
  #20
Lives for gear
 
Joined: Dec 2003
Location: Calgary, Alberta
Posts: 1,127

Thread Starter
dale116dot7 is offline
Ok, this morning's playing around...

Delay 1 = 130ms
Delay 2 = 173ms
Delay 3 = 207ms

Feedback = 73% on all loops.
Taps, delay 1, at:
21ms, -4dB
71ms, -6.5dB
102ms, -9dB

Taps, delay 2, at:
47ms, -4dB
112ms, -7dB
152ms, -8dB

Taps, delay 3, at:
40ms, -8dB
101ms, -11dB
147ms, -14dB

I started in mono. I found that just twirling the delay dial to roughly distribute all of the taps seemed to be not horrible for even time response - a drummer's count-in shows a whole bunch of sharp 'ticks' that don't bunch too much - just a bit. But moving each tap around just a little on snare or noise made a difference. But then I put in vocals, and I found that moving the taps around just a bit made the tone of the vocals change quite a lot - frequency colouration, I think. There's no feedback mechanism to ring at any frequency due to changing the taps around so it's just frequency response of a not particularly well windowed FIR filter.

Then I moved the pan pots on my console out to the extremes. That messes with your head. I was using headphones. The taps were distributed hard left and hard right. It sounded better with the pan pots at 9 or 10 o'clock and 2 or 3 o'clock, and also levelling out the left and right so they were about the same in level seemed to make things work for me.

On impulsive sounds, this sounds pretty awful yet, but on vocals it's not a disaster, and on clarinet and melodica it's actually got a nice, spacey sound that suited what I was listening to - my band's rendition of 'People are Strange' with a lot of back-and-forth between those two wind instruments. The tail still has repetition, but I think that could be tweaked out a bit with matching tap and loop gains. I should be able to make an Excel spreadsheet to calculate those out. I guess another approach would be to distribute several small gain multiplies throughout each loop and keep the tap levels consistent.

Sloping the taps tends to reduce the 'tape looping' effect quite a lot, and to me it seems as though it should. In theory, I would think the gain should slope so that by the time the sound got from the last tap, through the feedback multiply, and back to the first, the slope should be about the same. I didn't do any math this morning (no coffee yet), so I just tweaked. I also left all of the gains of the same polarity, flipping those around should change the character of the frequency response, too.

The other thing that seems unnatural is something like the drummer's count-in. The sound stays too sharp for way too long. That's easy - put a first-order lowpass in each delay loop. I haven't done that yet, but it seems like that would improve the sound quite a lot.

What is interesting is that when you have all of these knobs to fiddle with, you can isolate things. For example, I found that one loop had more repetition than the other, so I just turned off all but that loop and fiddled until two of the loops had similar decay times and repetition. I can only have 60 knobs in my software, and now I'm wishing that I had finished the 'save effect settings' software. Ahhh, assembly code at six in the morning.

For those here who don't know how I'm doing this, I use a MC9S08AW60, 20 MHz, running the user interface. It interfaces to two in-series AL3201 'digital reverb engine' chips by Wavefront Semi, each of which can do about 110 instructions per program loop - I believe each AL3201 chip is roughly similar in performance to maybe a 224XL or maybe a PCM70, just judging from the information in the service manuals for those boxes. A CODEC, a 2x20 vacuum display, an input level bargraph, a few pushbuttons, and a rotary encoder completes the board.
dale116dot7
Thread Starter
#21
10th April 2009
Old 10th April 2009
  #21
Lives for gear
 
Joined: Dec 2003
Location: Calgary, Alberta
Posts: 1,127

Thread Starter
dale116dot7 is offline

It is real... there's blue jumper wires on there.
#22
10th April 2009
Old 10th April 2009
  #22
Lives for gear
 
Casey's Avatar
 
Joined: May 2003
Location: Cambridge MA USA
Posts: 1,268

Casey is offline
Nice looking board! Did you build that yourself?

So you are right on with both the tap slopes and the low pass filters on each delay loop. You might want to add a pair of low pass filters in series right on the input that would get you a 12dB rolloff at around 12khz.

Now put 3 allpass filters on each output. Play around with the sizes but to start out, take around 70% of the length of your smallest loop. Then divide this in two using the golden ratio you mentioned earlier. Make two allpass filters in series out of these delays times. Then add a third one that is fairly small say around 2.5 ms. from largest to smallest use say .35, .45, .6 for the gains.

Then reduce the size of all of the allpasses on the left by 5%, and increase the size of the allpasses on the right by 5%. Also alternate negative then positive then negative feadback on the three series allpasses on the left, and do just the opposite on the right, positive, then negative, then positive.

Now there is more to play with.



-Casey
dale116dot7
Thread Starter
#23
10th April 2009
Old 10th April 2009
  #23
Lives for gear
 
Joined: Dec 2003
Location: Calgary, Alberta
Posts: 1,127

Thread Starter
dale116dot7 is offline
Yes, I did the layout and hand-built two of them. I'm planning on migrating from the AL3201 processor to that 'real' DSP - the DSP56366. I gave it 512k of SRAM, but I mapped it in two chunks with a hole in the middle so the number of address lines on the outside of the chip cause the memory to wrap around so you can use a simple delay line without using the modulus operator, which in the DSP56300 family, is limited to 32k.

Ok, I'll try that probably tomorrow morning. This is getting interesting. The three separate loops are really neat. I am amazed at how the three loop simple 'slapback' delay actually begins to sound like a reverb and not just a simple Sun Records style of delay. I know the original allpass loop arrangement didn't do this, I've not actually seen this sort of arrangement except in the context of an FDN.

Another thing that is popping out at me is to cross-couple the loops a bit to simulate corner modes.

I've also got a pretty big inventory of other DSP's - at least for a hobbyist. I have a few Spartan-3E FPGA's, a tray (60) of the older DSP56002's, and about 20 of the AL3201's in a rail.
#24
11th April 2009
Old 11th April 2009
  #24
Gear addict
 
zmoorhs's Avatar
 
Joined: Feb 2009
Posts: 330

zmoorhs is offline
Quote:
Originally Posted by Casey View Post
Now put 3 allpass filters on each output. Play around with the sizes but to start out, take around 70% of the length of your smallest loop. Then divide this in two using the golden ratio you mentioned earlier. Make two allpass filters in series out of these delays times. Then add a third one that is fairly small say around 2.5 ms. from largest to smallest use say .35, .45, .6 for the gains.

Then reduce the size of all of the allpasses on the left by 5%, and increase the size of the allpasses on the right by 5%. Also alternate negative then positive then negative feadback on the three series allpasses on the left, and do just the opposite on the right, positive, then negative, then positive.
Sorry if this is a dumb question, but what type of allpasses are you talking about? Is there only one type used in reverbs?
#25
11th April 2009
Old 11th April 2009
  #25
Lives for gear
 
Casey's Avatar
 
Joined: May 2003
Location: Cambridge MA USA
Posts: 1,268

Casey is offline
Quote:
Originally Posted by zmoorhs View Post
Is there only one type used in reverbs?
Well yes, but you may consider nested or modulated versions as new types, but in general there is just the one type. Have I misunderstood your question?



-Casey
#26
11th April 2009
Old 11th April 2009
  #26
Gear addict
 
zmoorhs's Avatar
 
Joined: Feb 2009
Posts: 330

zmoorhs is offline
Quote:
Originally Posted by Casey View Post
Well yes, but you may consider nested or modulated versions as new types, but in general there is just the one type. Have I misunderstood your question?



-Casey
No, I'm probably just missing something. I thought there were more than one type of allpass, one of the differences being the decay slope, or am I getting confused with combs with that?
#27
11th April 2009
Old 11th April 2009
  #27
Lives for gear
 
Casey's Avatar
 
Joined: May 2003
Location: Cambridge MA USA
Posts: 1,268

Casey is offline
Quote:
Originally Posted by zmoorhs View Post
No, I'm probably just missing something. I thought there were more than one type of allpass, one of the differences being the decay slope, or am I getting confused with combs with that?
Hmmmm, not really sure what you might be thinking.

Perhaps you are thinking of the gain of a particular allpass? This would effect the "decay time" of the allpass.



-Casey
#28
11th April 2009
Old 11th April 2009
  #28
Lives for gear
 
Casey's Avatar
 
Joined: May 2003
Location: Cambridge MA USA
Posts: 1,268

Casey is offline
Quote:
Originally Posted by seancostello View Post
Barry Blesser has a recent patent that addresses this issue. Blesser introduces a filter type called "notchpass," where the group delay peaks are matched to corresponding minimums in the frequency response. In the feedback loop of a comb filter, the result is a reduction or elimination of the metallic sounding frequencies sticking around.

I haven't tried this, as I first read about it in an issued patent, and it was not in any prior art that I know of. I tend to deal with these allpass issues by reducing the coefficients to lower levels, by randomizing things over time, or by not using allpasses.

Sean
I would agree with you on how you deal with allpass filters.

I have listened carefully to this idea in practice. It has the most applicability in longer reverbs that pass the same signal through many passes of the same allpass (or notchpass using Barry's method).

It is very clever and absolutely does what you say; it eliminates metallic qualities in the tail.

The problem is that it colors the early part of the reverb in an undesirable way. The argument is that the early reverb is dominated by the dry signal, but I still feel that (with all it's artifacts) modulated allpasses still sound better.



-Casey
dale116dot7
Thread Starter
#29
11th April 2009
Old 11th April 2009
  #29
Lives for gear
 
Joined: Dec 2003
Location: Calgary, Alberta
Posts: 1,127

Thread Starter
dale116dot7 is offline
With the allpasses added, it sounds like a reverb. Still, some looping sounds, but ignoring those, the rest sounds pretty good now. I evenly spaced out all of the taps, made the loops equal to 20k (at 48kHz) and split them up 1:1.272:1.618. I needed close to 10k for the output allpasses and I only have 32k on this chip to work with. The allpasses were made to your suggestions, though I didn't play with the allpass size yet. With no gain in the output allpasses, the signal was pretty close to what I had dialed in last time. Adding the allpasses makes it sound like a reverb. I just used your gains, though I could scale them up so I can try too much of a good thing. By changing the tap location in the loops, you can change the colouration quite a bit, just like last time. Close to evenly spaced seems to work well. I have an 8-bit scalar for tap locations (actually, all parameters), so you can't dial in to the nearest sample from a knob, but that probably makes it so that the taps aren't exactly at multiples of each other thanks to rounding.

I can see one of my next steps probably should be to calculate the tap slope to correspond to the decay value used at the end, which should get rid of, or at least tame, the repetition, then go back and revisit the tuning of the taps without output diffusion so you can hear that part better.
#30
11th April 2009
Old 11th April 2009
  #30
Lives for gear
 
Casey's Avatar
 
Joined: May 2003
Location: Cambridge MA USA
Posts: 1,268

Casey is offline
Great!

Now (I hope you have the cycles for this) we need to introduce modulation.

As you mentioned the position of the taps have a large impact on the coloration of the reverb. To reduce this, the taps should be randomly modulated within a 5 ms window.

The modulation should be random as opposed to a chorus pattern. This can be accomplished using a table of random offsets. The taps can be moved using linear interpolation with at least 16 steps between samples. Use the table to define a new offset for whichever tap finishes it's traversal during the current sample time processing.

Play with the speed of the tap movement (and the resulting pitch effect) to meet your subjective taste.

It's going to start sounding nice now, but there are a few more steps to consider and a lot of tuning to go.



-Casey
New Reply Submit Thread to Facebook Facebook  Submit Thread to Twitter Twitter  Submit Thread to LinkedIn LinkedIn  Submit Thread to Google+ Google+ 
 
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Similar Threads
Thread
Thread Starter / Forum
Replies

Forum Jump

SEO by vBSEO ©2011, Crawlability, Inc.