Reverb Subculture

[dale116dot7]

Originally Posted by Casey

I agree with Sean there does seem to be some needed tuning of those output allpasses, I'm sorry my sizes were probably not ideal.
You can increase your modal density by implementing the simplest form of the FDN. Simply take the output of loop1 and instead of feeding it back to loop1 feed it back to loop2, then loop2 to loop3 and loop3 to loop1.

Ok, I see. There are still three sets of three taps, three injection points, but one 'big loop' instead. That should reduce the looping sensitivity as the sounds loop through different delay lines and more particularly, through all of the RT multipliers, so that should automatically match the RT gains between the loops. But before I do that, I would like to get the 300 Hz comb under control. Even though the chorus moves the taps around and makes that drift around, I still hear it as a colouration that I don't like.

I guess one of the things I could do is invert one tap at a time and see when the 300 Hz null turns into a 300 Hz peak. That should be the culprit.

[dale116dot7]

Tonight's progress...
I coupled the loops as you described, that stabilizes the tail quite a bit. I also added host software to slope the taps with the RT multiplier, and that also helps. At longer RT settings (a gain of greater than 0.7), it sounds pretty good. I put it up against the PCM91 'Vocal Magic' preset, and I would put it in a similar quality level to that - similar enough that I could use either as a vocal reverb and be happy with either.

I also added three loop allpasses with a setting that allows you to turn them off (0), turn them up to a reasonable level (50), or turn them up so much that they ring (100). On vocals the effect is subtle, I wouldn't mind either one. On percussion, the change is dramatic. I like the idea of one algorithm doing both a constant density and a building density with the twist of a knob.

The one thing that happens now is for shorter RT's, the left output decays faster than the right output - you hear a dramatic 'twist' to the tail. At long RT's that 'twist' goes away. I have my taps arranged as follows:

R: dly1[1371], dly1[6056], dly2[5230], dly3[2217], dly3[10252]
L: dly1[4113], dly2[1742], dly2[9473], dly3[6656]
fb: dly1[8227], dly2[10462], dly3[13312]

Also, for short sizes, the sound gets a bit choppy or something. I set the program for a maximum size of about 56 metres, and it goes down to 12 metres and sounds ok, but below that it sounds a tad bit odd.

[Casey]

Wow, that is terrific!

As for the delay fading on the left, did you try evening out the output allpass sizes? Looking at your tap layout you might want to make the left output allpass sizes a bit larger than the right.

Also, could it be from output taps that are within a loop allpass? (does it happen when the loop allpass gains are at 0?)

I'll bet the choppy sound is something not being sized correctly (taps outside of loops, that sort of thing)

I can't wait to hear it.



-Casey

[dale116dot7]

Turns out that my left allpasses are shorter than my right allpasses. I'll try reversing the sizes.

I'm not so sure that the 'choppiness' isn't actually some amplitude variation through the loops that sort of wavers gently at large sizes, but then gets faster - and more noticeable - at smaller sizes. It happens with or without loop allpasses, and it comes on gradually with size reductions. That would indicate either my output tap gain or loop gain tuning needs a bit of work. Since I use an algorithm to calculate that out, that probably needs some work. It also gets better at extremely long RT's and worse at shorter RT's, so it seems as though it's in the feedback path, which is pretty simple - three gain multipliers. I should check the calculations on those feedback path numbers.

I'll run some more rough mixes through once I get the remaining problems fixed. The combing is gone, I must have had a programming mistake because when I split the algorithm up into the two chips, I needed to change about four lines to transfer the raw tap data from one chip to the other. The problem went away as soon as I did that, so I probably had one instruction in the output tap section that didn't clear the accumulator when I expected it to be zero.

[Casey]

Does the "wavering" happen when the chorus it turned off?

I wonder if this is just the hf rolloff that is caused by the linear interpolation?



-Casey

[dale116dot7]

I did it with and without chorus. After redoing my calculations for tap and feedback amplitudes, it's a lot better. I calculate the RT's and tap gains for each of the loops based on a continous slope, and after the RT feedback, the first tap will be at close to the 'correct' level had the loop been unrolled. It works well with the innermost feedback gain set to 0.45 or higher. Below this, the sound is pretty uneven and choppy. I would suspect that is because the number of taps vs. how long the sound stays in the loop makes the sound disappear before the output allpasses have had a chance to build up any energy - thus a choppy sound. The room size no longer causes a waver, but it also doesn't really sound that great under about 10 metres - using 32k split between the three loops comes out to about 52 metres for the shortest distance.

[dale116dot7]

I think a solution to the small-size sound would be to size the output allpasses not linearly with the loop size, but in some other relationship 'tweaked' to get the sound right. It sounds close, but not quite right. A table lookup and interpolate is trivial, so making them nonlinear is easy.

Above 10 metres (about 6k of memory used), it is fine. Above 20 metres it sounds quite good. That is a 5:1 range of sizes for one algorithm, that has about the same ratio limits as the PCM70's plate and chamber algorithm size range (they go from around five metres to around thirty). It is possible that changing the output taps around at a small size might make it sound better smaller, and then it should sound good when sized up. Do you ever find the need to shift the output taps any way but linearly with size? Also, is there any reason to increase the number of taps on this algorithm? Is that something to experiment with? Or do you have another 'next thing to do' that's even better?

Now,

[seancostello]

Regarding the sound at small sizes, one important thing is what your total modal density is at that size setting. The length of the longest delay is used in some reverbs to determine size, but I would think that it would be more important to try and match the sum of the delay lengths to the room size. Of course, a large hall has a few orders of magnitude more resonances than what a digital reverb usually has, but perhaps there is some metric that would be useful.

One possibility is to have the Size control match up with the predicted Schroeder frequency of a space. In other words, your average density of resonances per Hz for your artificial reverberator (which, for a conventional delay based single band reverberator, is constant across all frequencies) matches the modal density at the Schroeder frequency of an "ideal" rectangular space with the longest dimension corresponding to size. Someone who has had more sleep than me can probably explain this better, or better explain why my idea is totally wrong.

EDIT: OK, my idea is probably wrong, in that I think that the Schroeder frequency is DEFINED by having X amount of resonances per Hz. So, maybe a better idea is to match the resonance density of the reverb (totalDelay/samplingRate) to the resonance density of the modeled space at some particular frequency, like 1000 Hz or so.

Of course, the structure that Casey was discussing was loosely based on the EMT-250, which didn't have enough modal density to emulate anything but the tiniest of spaces. The modulation tricks Casey is discussing are used to turn the discrete resonances into statistical peaks. The goal of the modulation is that the peaks become wide enough to "fill in the gaps" between each other, thus emulating the effect of having far more peaks per Hz. Again, others can explain this better than I can, with Barry Blesser's work being a good start. I always view the resonances as a picket fence, with the modulation moving the fence back and forth such that it appears to be a solid surface with some degree of transparency.

Another idea is to not worry about emulating a physical space with this algorithm, and make it more of a "plate." Some recent papers I have read suggest that plates have a fairly constant modal density across the audio range - around 1.27 resonances per Hz on average. So, give yourself 60K of total delay time for a 48K sampling rate, and then put in taps and allpasses and scattering and stuff until it sounds like a plate. Just that simple.

I love this thread, BTW. Love love love it. I have been following along with my VST code, and my algorithms are improving as a result. My EMT-250 type algorithm sounds OK, although I am having some technical issues with the modulation on my end, but working on this resulted in some breakthroughs on modulation in general that I can apply to my existing code.

[Casey]

I'm going to start backing out slowly now with respect to specific "next steps".

I think an important goal has been reached. The basic building blocks are now set out, and through just the first week or so of this thread, I think it has been shown that these blocks can sound great, even when put together in the most basic ways.

The more general "next steps" are to refine understanding and use of these building blocks, and how to further manipulate them to match your desired model and future goals when you feel comfortable moving beyond existing models.

I would love to keep chiming in on the technical aspects though. In particular there seems to be gaps in many basic descriptions of what is going on within a room or an artificial reverb.

The modal density question is a good one. Knowing what defines it in an artificial reverb is the first step to knowing how to control it.

The modal density is the superposition of the frequency response of all of the feedback and feedforward paths in the recirculation part of the topology, excluding the ones within any allpasses.

What defines the recirculation part of the topology?

What defines a feedback path, and what defines a feedforward path?

I mentioned earlier that having a balance of both types of paths is a good thing; why is this?



-Casey

[dale116dot7]

No recirculation or no feedback gives a slapback or a bunch of slapbacks. That can sound good if you have enough taps.... convolution. Without recirculation you should get an 'inverse' or 'gate' effect - or an RT that is only as long as the memory you have with an abrupt and unnatural cutoff. Seen that here.

Although an interesting effect is the 'black hole' reverb - something like fifty or so allpasses in series, with the output at the end and no recirculation except the feedback paths in each allpass. It gives a very slow buildup, and an almost symmetrical tail. I call it an effect because it is just that. But perhaps taking some taps throughout can shape this to be a useful reverb. It's on an Eventide.

Speaking of inverse or gated reverbs, if you can't recirculate because of the desired sound - after all, a gated reverb is supposed to cut off - I guess what you'd have to do is unroll the loops (just use a straight multitap with lots of taps) to the length or 'gate time' that you wanted, and use the slope of the output taps to shape the envelope.

[seancostello]

Originally Posted by Casey

The modal density question is a good one. Knowing what defines it in an artificial reverb is the first step to knowing how to control it.

The modal density is the superposition of the frequency response of all of the feedback and feedforward paths in the recirculation part of the topology, excluding the ones within any allpasses.

I presume that you are referring to the delays within input or output diffusion allpasses, and not the delays within allpasses embedded within the recursive part of the reverb.

I was thinking about modal density versus the "size" parameter. In most reverbs I have seen, increasing size by a factor of 2 simply scales the delays by a factor of 2. This maps size to the length of the longest delay in the room, or how long it takes for an input signal to bounce back.

In a real acoustic space, increasing the room sizes by a factor of 2 will increase the volume by a factor of 8; in other words, the volume increases as the square of the size increase. However, the Schoeder frequency is calculated as 2000*sqrt(RT60/volume), so the Schroeder frequency maps more linearly to the size parameter - as the size is increased by 2, the Schroeder frequency is decreased by 2.

Reverberators based around digital delay lines have a resonance density that is constant across all frequencies, versus real acoustic spaces where the density increases with the square of frequency. In a digital reverberator, the average modal density will vary linearly with frequency, and the Schroeder frequency will vary as the inverse of the size decrease. So it seems like mapping the size parameter linearly to the increase in the delay line lengths seems like a good idea, at least from a perceptual perspective.

Sean

[Casey]

Originally Posted by seancostello

I presume that you are referring to the delays within input or output diffusion allpasses, and not the delays within allpasses embedded within the recursive part of the reverb.

The feedback and feedforward paths of allpass filters in the recirculation part of the reverb play no role in determining the modal density.

To the extent that the allpass filter also contributes delay (as you are pointing out) to a feedback path that is separate from it's own feedback path, it does contribute to the modal density of the containing feedback path.



-Casey

[Casey]

Originally Posted by dale116dot7

At longer RT settings (a gain of greater than 0.7), it sounds pretty good. I put it up against the PCM91 'Vocal Magic' preset, and I would put it in a similar quality level to that - similar enough that I could use either as a vocal reverb and be happy with either.

I can't wait to hear it!



-Casey

[dale116dot7]

Besided doing a nice session in my studio the last few evenings, I've been working away at my DSP56366 board with the intent of putting this (and other effects) algorithms into it. I've managed to get a lot of the basics running, after many hours of work. I still have to write parameter passing software between the DSP and the Coldfire UI processor, but after that, I should be pretty close to ready to implement this algorithm on the new PC board.

This might be a bit much to ask, but I'll ask it anyways. The DSP56366 has a modulus addressing mode to make circular buffers (ie. delays). But the maximum circular buffer size is 32,768 samples. Would you use this and just make a bunch of them in memory, or would it be better to just use memory mirroring and make the entire 512k look like one huge shift register?

-Dale

[Casey]

Originally Posted by dale116dot7

The DSP56366 has a modulus addressing mode to make circular buffers (ie. delays). But the maximum circular buffer size is 32,768 samples. Would you use this and just make a bunch of them in memory, or would it be better to just use memory mirroring and make the entire 512k look like one huge shift register?

Congrats on getting another board up and running!

I have always used multiple small buffers. But that is just how I like to organize things. I'm sure we have both seen it done either way.



-Casey

[dale116dot7]

That makes sense with the hardware at hand. With the Lexicon PCM70/480L and earlier hardware it makes sense to treat the memory as a big shift register as you don't really have any other option.

I'm just starting to work on the host-DSP interface. I've started to figure out how I should be setting up the DMA channels to support that, and I'm using an interrupt line from the host to the DSP signalling the start of a transmission. Hopefully I'll try that tomorrow.

[dale116dot7]

I've been trying to figure out if there's a more efficient way of doing this:

move x:(r3)+,x1 ; grab number of allpasses
move x:(r3)+,x0 ; grab coefficient
move x:(r3)+,r4 ; grab start of allpass pointer...
do x1,allpassloop
move x:(r3)+,r5 ; grab end of allpass pointer
move y:(r4+n4),a ; get input (start of allpass)
move y:(r5+n5),y0 ; get end of allpass.. generates pipeline stall by using r5
macr -x0,y0,a y0,b ; multiply end data to
move a,y1 ; save result for now... generates pipeline stall by reading accumulator
macr y1,x0,b x:(r3)+,x0 ; mac to generate output, next coeff
move a,y:(r4+n4) ; first mac, send back to input
move x:(r3)+,r4 ; grab start of allpass pointer, generates pipeline stall by fetching pointer r4 being reused at top of loop
move b,y:(r5+n5) ; store end of allpass
allpassloop:

It's an allpass, if you guys haven't guessed. It takes about 15 clock cycles per loop (one loop per allpass) which seems pretty high to me. I'm used to the AL3201 which does it in two cycles. Too many stalls, the assembler is talking, I'm hearing, but not understanding. Any ideas? Any DSP56300 programmers out there???

[Nishmaster]

I don't really know anything at all about ASM, or that DSP, but doing some google hunting and manual reading seems to suggest that data ALU operations take 2 cycles to complete, perhaps that's what you're running into here:

macr -x0,y0,a y0,b ; multiply end data to
move a,y1 ; save result for now... generates pipeline stall by reading accumulator

Dale, I've been following your progress both here and on groupdiy and it certainly fascinates me. I'm a programmer more than an analog designer, so do keep me in the loop with what you have going on with this project. Here's the 56300 Family Manual that I found:

56300 Family Manual

[dale116dot7]

Thanks for looking at that. I cycle counted as per the instruction sheet in the family manual's instruction timings. The frustrating thing I am finding is a lot of pipeline stalls, but I haven't managed to figure out how to get the algorithm to work with more parallel moves and no pipeline stalls. I probably just have to work away at it to see if there's a better way. I can see shortening it slightly by block processing the allpass but I don't see saving that many cycles. I'm still in a sample-by-sample way of thinking, but I don't see more than a cycle or two of savings here by eliminating reloading of coefficients because I'd just get more ALU stalls from the looks of it. If I were using SDRAM and caches it would certainly be a lot different as we've discussed before. Perhaps processing two allpasses in parallel using more instructions but doing two at once (interleaved) might be more efficient.

I can see an advantage of a VLIW architecture in terms of optimizing data flows through the pipeline registers. I actually could use a read of a register during the pipeline stall period for a useful function but the 56k doesn't allow that. But on the other hand, I've only spent a few days writing 56k code and I already have the audio and host interfaces, memory management, loop gains, and multitap summers tested and working, and the allpass is the one I'm battling now. The learning curve of the 56k is quite low, I've programmed in assembler on a 68k and the 56k is in the same line of thinking from a programmer's point of view.

I might be able to speed up the processor clock another 20 MHz - I'm at 98 MHz and it's a 120 MHz part, but then I'd have to go to two wait states on the SRAM and with four accesses here, it would be faster to stay at one wait state (the minimum) and run at 98 MHz. I am actually quite surprised that the data bus running at 100 MHz doesn't appear to get thrashy at all even on a two-layer PC board. But the bottom is uninterrupted copper, and that was a bear to lay out. Basically, the whole data and address bus - 19 address, 3 control, and 24 data bus lines all on one side of the board, with ground plane on the back. Perhaps I should try it at 120 MHz to check my timing margins.

-Dale

[Nishmaster]

Originally Posted by dale116dot7

I actually could use a read of a register during the pipeline stall period for a useful function but the 56k doesn't allow that.

That's odd. My understanding was that the assembler just inserted NOOPs where it detects pipeline stalls. If you can fill the NOOP periods with useful instructions, wouldn't that work?

I'm not sure what your limitations are with getting at registers at that point are, though. I'm sure my lack of knowledge here is showing rather evident, but just thinking off the top of my head.

[dale116dot7]

The assembler doesn't - the DSP56300 pipeline scheduler does that for you, but the assembler does warn you. But I did up a quick multitap delay and a few delay loops and allpasses, and found that the actual application speed (in terms of all-passes or taps or filters or loops) is about triple that of the AL3201 that I'm used to - and multitaps are quite quick, actually. I am looking at modifying my multitap algorithm to alternate taps, requiring an even number of taps, but doing MAC's to both accumulators, and summing the two up at the end. That would make taps pretty cheap - probably three clock cycles per tap. If you were looking for a straight FIR-based multitap delay, you could do 500 taps that way per sample. Or a 'convolution' of 10 milliseconds. I'd probably offer both algorithms - one for 4 or fewer where it's cheaper not to take the cycles to sum at the end.

The DSP56k is not nearly as impressive as the ADI Tigersharc or any of the VLIW processors in terms of performance, but reasonably easy to work with for a DIY box.

[seancostello]

Originally Posted by Warp69

Would you consider a 32 steps interpolation good enough for high-end reverbs?

I currently use 256 steps - the high quality interpolators in Eventides uses 128 steps.

I just posted about Lexicon interpolation in the Lexicon Bestiary thread, and this prompted me to look at some old Blackfin code of mine from July 2006. I figured this thread would be the better place for the DSP geek stuff.

The code implemented cubic interpolation, for control rate modulation of delay lines, in a VisualAudio feature that was never implemented. I used a 32-bit signal for the modulation, and had the modulation width as an argument to my function. From the maximum modulation width, I calculated the shift and scale amount for the cubic interpolation. What is weird is that the amount of bits in the fractional signal would vary depending on what I set the modulation width at. I am kind of impressed with myself for figuring that out (I haven't touched fixed point DSP in years, and was looking at the code thinking, "I wrote THAT?"), but in retrospect, it would have made more sense to assign a fixed number of bits to the fractional part of the interpolation, and work from there.

Having the modulation width as an argument may have also been a way of dealing with memory access issues on some of the ADI parts. I had an idea back then about using a precalculated modulation width to tell the DSP how much memory should be brought into cache, or how large of a DMA should be started, such that the interpolation could be performed on the memory on the chip (cache for the Blackfin, internal memory for the SHARC). I don't think that this ever got implemented, but it would certainly make sense for small amounts of modulation, where you are not randomly jumping around large distances on a sample-by-sample basis.

IIRC, Dattorro mentioned the idea of using 256 steps for his allpass interpolation, as this helped avoid issues when the allpass coefficient got too close to +-1.0. It is interesting to consider how many steps are considered good enough. If your numeric system is based around 16 bit fixed point, it seems like the number of steps in your interpolation will be determined by what your modulation width needs are. For microtonal modulation such as in reverbs and choruses, you will probably want to have 6 to 8 bits of precision for the integer part of your delay modulation, with the rest assigned to the fractional part. For pitch shifting...wow, I don't know. Double precision, maybe?

My instinct is that, if it is good enough for Eventide, then go for it. I think that most of the Eventide boxes nowadays are based around Freescale 56K processors, so the modulation signal would have 24 bits in single precision. 128 steps for interpolation yields 128K of addressable integer delay locations, which sounds like a lot, but is probably necessary for some of the pitch shifting operations with large windows. The interpolation coefficients are probably updated at the control rate, since it is a control rate operation. I don't know what the Eventide control rate is.

Most of my recent code has been floating point, and I haven't used fixed point for the interpolation, but I may try this out again. I would need to write fixed point modulators, otherwise there would still be a float to int cast, which is probably where most of the cost of my interpolation lies.

Sean

[Casey]

Originally Posted by seancostello

The code implemented cubic interpolation.

Don't get hung up on yesterdays constraints. Today, most algorithms are expected to run at 96k. At this sample rate, linear interpolation will only impinge down to roughly 24k (which I cannot hear.)

Originally Posted by seancostello

IIRC, Dattorro mentioned the idea of using 256 steps for his allpass interpolation, as this helped avoid issues when the allpass coefficient got too close to +-1.0.

Whisky Tango Foxtrot??? When (I mean really when) are you going to allow allpass coefs to get any where near +-1.0?



-Casey

[seancostello]

Originally Posted by Casey

Don't get hung up on yesterdays constraints. Today, most algorithms are expected to run at 96k. At this sample rate, linear interpolation will only impinge down to roughly 24k (which I cannot hear.)

Yeah, but us plugin folks still run things at 48K much of the time, where linear interpolation is quite audible. I put an Infinite button on one of the reverbs I have been working on, and after about a minute, the high end had gone away. I was using linear interpolation. Meanwhile, the same controls on an algorithm with allpass interpolation resulted in a nice ambient pad that went on and on without any high end loss.

Plus, the VisualAudio code was developed on a Blackfin EZ-KIT, with a fixed 48K sampling rate. Not to mention the noisy convertors that pass DC. Oh wait, I guess I did mention that. Anyway, we couldn't presume high sampling rates, or high end audio for that matter. At the time, folks at ADI were amazed that we were getting any sort of decent audio quality out of the Blackfin, as the Blackfin was originally developed as a chip for a laser printer. The Bricasti was one of the first products that demonstrated that the Blackfin could be used for high quality audio - I think it was Denis Labrecque that dragged me over to your booth at an AES show to see an early demo of the reverb.

The linear interpolation sampling rate argument makes a lot of sense for hardware boxes that run at higher sampling rates, or for running in an upsampled environment, such as might be used for tape echo or vintage BBD flangers with distorted feedback.

Whisky Tango Foxtrot??? When (I mean really when) are you going to allow allpass coefs to get any where near +-1.0?

1st order allpass with single sample delay, not the allpass delays we have been talking about in this thread. In 1st order allpass interpolation, instead of cross-fading between two delay locations separated by a sample, the fractional part of the interpolation signal is used to control the coefficient of a 1st order allpass filter.

The coefficient can get very close to +-1.0 as the interpolation approaches the integer boundaries of the delay line. Coefficients that are too close to +-1.0 result in a ringing allpass, with the sonic result being unpleasant noise and distortion in the output. Warping the fractional part of the interpolation signal to better approximate linear control over the allpass delay helps, as the warping function (an approximation of (1-frac)/(1+frac)) results in the allpass coefficient spending far less time in the extreme coefficient settings. However, quantizing the coefficients to 256 settings would also help with this.

As far as delay based allpasses having their coefficients being set too close to 1.0, I have heard this in a few commercial systems. One was the reverb that came with the original Unreal video game engine, that was clearly an allpass cascade with no global feedback, similar to the original Schoreder design, or to Chamberlin's reverb in his book. The allpass coefficients were used to control the reverb decay, which became obvious when really long reverb settings resulted in the straight signal becoming much louder than the reverb signal. I can cut them some slack, as having a reverb at all was an admirable achievement for video game engines at the time. The reverb sounded better than the Half-Life engine, for example.

My Ensoniq DP/2 also seems to have the ability to set the allpass coefficients way too close to +-1.0. The Large Hall algorithm sounds similar to the PCM70 Concert Hall algorithm that I have heard, but the Ensoniq has STUPID coefficient ranges. Turning up the Definition to 99 seems to set some of the loop allpasses to coefficients of 0.99. I don't mind giving the user enough power to do cool things, but giving someone raw control over this, without explaining what ranges to avoid, will inevitably result in horrible sounding patches.

Sean

[dale116dot7]

It's interesting that you brought this up right now. I've just gotten most of the 'basics' on my DSP56366 reverb working. No presets, no saving of effects, and only a single algorithm. But I can vary the parameters manually, and reload firmware to adjust the algorithm.

Just to test the performance, I set up 72 output taps, three loops, eight allpasses, and two low-pass filters. That all takes 8.3 microseconds. That ends up being about double that (double the speed - half the time) of an AL3201, or I would guess about three times the performance of a Lexichip, which isn't hugely fast, but not bad, either. But I can see how I could cut that almost in half - I just need to rewrite the multitap summer to not waste half of the clock cycles in pipeline stalls.

Anyways, glides and chorus are the next set of algorithms I want to look at. One option I was thinking of was making a high-boost EQ after the interpolate that varied its coefficient with the interpolation fraction, but that would be a bit tricky to get working, I think. Plus, unless the chorus was done entirely on the host, it would be more of a DSP hog to calculate the warping, though not horrible if there were only a couple of interpolates actually moving at any one time.

[zmix]

Originally Posted by seancostello

My Ensoniq DP/2 also seems to have the ability to set the allpass coefficients way too close to +-1.0. The Large Hall algorithm sounds similar to the PCM70 Concert Hall algorithm that I have heard, but the Ensoniq has STUPID coefficient ranges. Turning up the Definition to 99 seems to set some of the loop allpasses to coefficients of 0.99. I don't mind giving the user enough power to do cool things, but giving someone raw control over this, without explaining what ranges to avoid, will inevitably result in horrible sounding patches.

Sean

Indeed. I was hired as a consultant / real-world guinea pig by Ensoniq back in the 1990s. Several of the reverbs in the DP/2 and DP4+ (not the DP/4) were my patches. I later worked with Jon Dattorro on the reverbs in the DP/pro. There is a n algo in that box "Expert Reverb" which is based on the "Dattorro Reverb" mentioned in several AES papers, it was specifically written for the ESP-2 chip , also designed by Dattorro. Those were the days... design the chip to run your algos on rather than vice versa!!

Is is true that Lexicon have begun using off the shelf DSP rather than proprietary chips in the new PCM-96?

[seancostello]

Originally Posted by zmix

Is is true that Lexicon have begun using off the shelf DSP rather than proprietary chips in the new PCM-96?

It is true. The PCM96 is based around an Analog Devices TigerSHARC. I am unsure which one. This is theoretically off the shelf, although trying to order them as a smaller company can be a bit problematic.

Sean

[zmix]

Originally Posted by seancostello

It is true. The PCM96 is based around an Analog Devices TigerSHARC. I am unsure which one. This is theoretically off the shelf, although trying to order them as a smaller company can be a bit problematic.

Sean

And has anyone (besides Lexicon, of course) compared the sound of the algos in the PCM96 against the proprietary hardware from which they were derived?

[Michael Carnes]

Originally Posted by seancostello

It is true. The PCM96 is based around an Analog Devices TigerSHARC. I am unsure which one. This is theoretically off the shelf, although trying to order them as a smaller company can be a bit problematic.

TS-101. 3 banks of 64K words (32-bit) on board. Three 128-bit internals busses and another 32/64-bit external bus. 8 megawords of SDRAM attached. Made by elves that live in a tree.

[dale116dot7]

Since I'm making a new PC board for my reverb - I built one and there are a lot of jumpers on it - I'm going to switch to a DSP56721, which has two DSP56300 cores, 248k (by 24 bit) internal RAM, 180 MHz, and an SDRAM interface. I'd like to put bulk delays in SDRAM and the smaller loops and allpasses and filters in internal RAM. Actually, with that much RAM, I doubt I'd even need the SDRAM for many algorithms - PC board design at 133 MHz is a bit tricky. Sticking to all internal RAM is comfortable, and with its internal SRC, I think a person could do a dry mix at 96k and down-convert to 48k for the reverb to keep the RAM use down. With two cores, it would certainly be possible to put one of them doing mostly internal small loops sample-at-a-time, and the other core dealing with longer loops in SDRAM and block processing them, or shuffle bits and pieces in and out of the internal SRAM.

That was the biggest complaint about SDRAM, but with a dual-core, I can see an easy way of organizing the software to take advantage of the simplicity of sample-at-a-time coding for some of the loops while also not choking SDRAM performance by doing out-of-page accesses all of the time while implementing things like long allpasses.

I think I'm going to try to put up some samples of my latest work on the algorithm we were working on. I added a lot of taps to the loops - brute force. It actually works pretty well without modulation with that many taps, I'm adding modulation this weekend. It is interesting to hear the sound as you slowly add taps. You can set the RT very low (I set it to zero) and diffusion to zero, and play a pulse (I use a click from a drum machine). You can hear gaps in the resulting sound and add taps to fill it in. At least that's what I was doing. But then you have to do a spectrum analysis with noise as the input to see the combing, and adjust things. I think I'm going to write up a little sheet in Excel to calculate the combing frequencies and try to optimize them that way, then try them on hardware - after getting the time-domain response close to how I want it.

NS: That's enough RAM to do some sampling like the 480L SME. Any programs like that on the '96?