What makes a digital reverb sound like spring, plate, hall, room...

[Fancy Lime]

Hi all,

I need a reverb and am thinking about whether I want to buy one (some decent but not great affordable options out there), build an existing design (Merlins Equinox or one of the many BTDR brick designs, possibly modded), or design my own. The question is, what are the parameters that make a reverb sound (approximately) like a spring, plate, hall, room, or whatnot reverb? I would appreciate some general design pointers in terms of decay, filtering, feedback, delay times, possibly modulation, etc.

Thanks,
Andy

[stallik]

I haven't looked at another reverb since building deadastro's chasm.

[Mark Hammer]

When it comes to reverb types using identifiable spaces as their category name (room, chamber, hall, cathedral) some of the characteristics are given by the space-name.  So one would expect reflections to begin a little later, and be spaced a little more widely, the larger the space is.  Plate reverbs are  prized for their bright sound, and long decay.

[DrAlx]

The "early reflection" component Mark refers to gives you the perception of room size.  The decay gives you a perception of reflectivity of the surfaces.  Different frequencies get affected in different ways according to the space (some scatter more than others) so LPFs and HPFs  in the delay loop can tailor the sound.  Spring reverbs get their springy sound from dispersion in the delay line.

I would go the digital route, get a SIP to DIP converter board and build something with an FV-1.
There are default reverbs on the chip.  If you have windows on your machine, you can even code your own.
Check out:
https://www.diystompboxes.com/smfforum/index.php?topic=118048.msg1098073#msg1098073
for a project that uses the default reverbs.
If you want the option of coding your own, then check out the files I posted here
https://www.diystompboxes.com/smfforum/index.php?topic=121408.msg1156740#msg1156740
Note that you don't need an FV-1 development board, just a cheap Arduino board and some wires.  If you don't want to write code, check out SpinCAD designer.

The PT-2399 (Belton brick) based "reverb"s lack a key thing that limits what you can do with them.  They don't have digital all-pass filters.  Digital APFs enable you to get a "wash" of sound in the reverb tail instead of a simple set of echoes.

You may be familiar with analog all-pass filters as used in phasers.  Those shift the phase of a signal, zero degrees shift at one end of the spectrum (e.g. at DC) and 180 degrees at the other end of the spectrum (e.g. at infinity Hz).
The digital APF is a slightly different beast. That phase shift of 0 to 180 degrees isn't stretched out across 0 to infinity Hz, but is crammed into a finite range of frequencies and then repeated periodically across the spectrum.
For example you could configure a digital APF that has 0 degrees phase shift at DC, 10Hz,  20Hz, 30 Hz, etc all the way to infinity, and 180 degrees shift at the frequencies in between (5Hz, 15Hz, 25Hz, etc).  You can go much finer than 10Hz repetition of course.  Put a few different APFs into the delay loop and it kind of scrambles the phase shifts experienced by different frequencies, so you get a wash of sound in the reverb tail instead of a set of noticeable repeats.  The digital APF is what made digital reverbs possible.

[anotherjim]

Pre-delay. The larger the room, then the longer delay time is before any reflections happen. Sound travels very approximately 1 foot (300mm) in a millisecond. A single PT2399 before a PT2399 based Belton brick would give a pre-delay no shorter than 30 or 40ms so that chip may not go short enough for small spaces. On top of that, the first "Early" reflection also has to travel back the same distance. However, the brick would have some pre-delay equal to the shortest delay in it. The bricks pre-delay is therefore fixed. Effective pre-delay would be the pre-delay PT2399 + the earliest delay out of the brick. Strictly speaking, the bricks first delay should equal the pre-delay added in front but that isn't going to happen.

Spring reverbs are much more difficult to simulate (so use a real one?). Many commercial products chicken out of giving a spring emulation even when that might be more appropriate.

[Fancy Lime]

Thanks for the clarification, guys!

I think for a simple reverb the minimum room size of the belton bricks is fine for my purposes. I have looked into some designs and think it should be possible to make something fun very easily. Maybe using individual PT2399's should be the second step but of course it opens a lot more possibilities. Spring reverb can play hide and go f*** itself, as far as I'm concerned. I never understood why people are so after digitally simulating the bad analog simulation of actual reverb. Definitely my least favorite reverb type after shimmer, modulated, and all the other fancy newfangled nonsense. </GrampaSimpsonRant>

Something FV-1 based may also be interesting but a much more massive endeavor, so I think that may be pushed a little down the road. And then I think it is more likely to become a multi effect rather than just a reverb. That chip offers a lot of possibilities but requires a lot more research on my part before I even know what to do with it. Anyway, I'll try and find some existing designs and see if I can work my way to something easy and useful from there. Never done any chip programming but I'll have to start at some point, I guess.

What turned me away from the FV-1 initially was that I assumed (without any reason, now that I think of it...) that that was the chip in the oh-so-many cheap and tiny commercial reverb pedals. Most of those sound really underwhelming to me. But now that I heard a few examples of DIY FV-1 effects, I must say, those sound great. So I'll have to retract my baseless assumption...

Cheers,
Andy

[ElectricDruid]

What turned me away from the FV-1 initially was that I assumed (without any reason, now that I think of it...) that that was the chip in the oh-so-many cheap and tiny commercial reverb pedals. Most of those sound really underwhelming to me. But now that I heard a few examples of DIY FV-1 effects, I must say, those sound great. So I'll have to retract my baseless assumption...

As you've realised, that only proves that there are a lot of sh!t coders out there. The chip itself is no powerhouse, but with some cunning coding by people who understand it, it's been used to get some effects that sound a hell of a lot more expensive than they are.

[Fancy Lime]

What turned me away from the FV-1 initially was that I assumed (without any reason, now that I think of it...) that that was the chip in the oh-so-many cheap and tiny commercial reverb pedals. Most of those sound really underwhelming to me. But now that I heard a few examples of DIY FV-1 effects, I must say, those sound great. So I'll have to retract my baseless assumption...

As you've realised, that only proves that there are a lot of sh!t coders out there. The chip itself is no powerhouse, but with some cunning coding by people who understand it, it's been used to get some effects that sound a hell of a lot more expensive than they are.

Haha, Tom you don't think that after that statement I'm not going to bug you with questions when I finally start a FV-1 project, do you?    I'm a pretty $#!+ coder myself, you know? At least I always think that when looking at my own code. But whenever I see some commercial program, meaning one where someone was actually paid real money to write code, I usually feel much better about my own programs...

Andy

[marcelomd]

As you've realised, that only proves that there are a lot of sh!t coders out there. The chip itself is no powerhouse, but with some cunning coding by people who understand it, it's been used to get some effects that sound a hell of a lot more expensive than they are.

A lot of shit coders out there: check.

I've been developing software for +- 15 years now. I've seen how the sausage is made. It's a miracle things mostly work.

[ElectricDruid]

Haha, Tom you don't think that after that statement I'm not going to bug you with questions when I finally start a FV-1 project, do you? 

You can bug me with questions, Andy, for sure, but I don't know the FV-1 at all. Never used it. Keep meaning to get around to it, but haven't managed. Maybe if coronavirus lockdown keeps me in the workshop for weeks on end some of this stuff might finally happen.

I'm a pretty $#!+ coder myself, you know? At least I always think that when looking at my own code. But whenever I see some commercial program, meaning one where someone was actually paid real money to write code, I usually feel much better about my own programs...

Yeah, I think actually being very critical of one's own work is generally the sign of a better coder. Or a better "X", actually - not just coders. People who take time to look at what they're doing and consider what they might be doing wrong tend to improve. Hopeless beginners tend to massively over-estimate their ability, whereas real experts are only too aware of all the stuff they *don't* know .

Sorry, drifting OT.

[Fancy Lime]

Alright, I looked into what few options for FV-1 development boards there are. Spin Semi's own Development board seems nice enough to experiment with. The EEPROM is socketed so it can easily be transferred to an actual effect. Would be nice to find a good generic ready-made PCB for that. The PedalPCB Module8, looks like a good choice. Alas, the information on the web page is pretty confusing. The build documents linked for the Module8 are called "Arachnid v2" but the PCB looks the same, so it may just have been renamed for legal reasons or something. What is more confusing, is that, according to the schematic, only the 8 external programs can be accessed (can easily be hacked to get access to the internal programs) but it is not clear if a pre-programmed EEPROM is included or even soldered in already. Well, probably, hopefully not, although that makes the whole sales pitch very strange.

PedalPCB is also coming out with an FV-1 Dev Board soon, which looks great at first. Essentially a programmable digital effect with everything included. BUT: For some reason they decided to hamstring it and only allow access to 3 programs on the external EEPROM and none of the internals. Assuming the CGI PCB pictures they have on their site are anything like the actual PCB will be, getting access to 4 programs each from the internal and external banks is a simple matter of not following the build instructions. Accessing all 2x8 programs would require cutting one trace and connecting one leg of the FV-1 to an auxiliary board. Seems doable.

Does anyone have any experience with PedalPCB? I cannot say that the webpage inspires confidence but that may not be an indicator of product quality.

Cheers,
Andy


EDIT: Mystery solved. "Arachnid v2" seems to be the name of the PCB which is shared by several effects. Looks like a case of the marketing department running the webpage instead of an engineer... Anyway, that makes a few things easier. Now all I need is a programming interface for a 24LC32A. Any suggestions?

Also, I just wondered: there must be commercial effects out there that use an FV-1 and a 24LC32A for modulation effects. Does anyone know if there is one that has decent peripheral electronics and a trough hole 24LC32A that can be replaced with a socket. May be a good deal cheaper and easier than building from scratch or based on a commercial PCB. And the hardware on far east guitar pedals is pretty darn decent these days (with some exceptions, of course).

[deadastronaut]

ahhh andy looks like your at the very same stage as me, great timing. i was curious about this fv-1 lark,

i just bought an fv-1 just to see what the ''internal'' sounds are like as i just couldn't find a demo

using guitar, which was very strange indeed....anyway with a little help from ice-9 mick on here (cheers mick)

i got it going enough to do a demo of the standard out of the box/chip sounds....using the
pedalpcb 'arachnid schematic btw.

here are the internal sounds.

i am now waiting on a pickit2 to mess around with the EEPROM for it....

if there are any other cheap quicker ways to programme the eeprom i'm all ears, as waiting on parts from china is a pain lol....

[DrAlx]

if there are any other cheap quicker ways to programme the eeprom i'm all ears, as waiting on parts from china is a pain lol....

An Arduino (or Arduino Nano).  See link I mentioned in my post above.  I include code for the Arduino program to write the EEPROM.

[deadastronaut]

ahhh cheers alex, i'll take a look....nice one. 

[ElectricDruid]

Presumably all you lot are running Windows? The problem I had was compiling code. The Spin assembler is windows-only. I found a Python-based thing for Mac OS, but haven't got far with it. I'd like to see a better toolchain for FV-1 on Mac. Anyone else in the same boat?

[Fancy Lime]

if there are any other cheap quicker ways to programme the eeprom i'm all ears, as waiting on parts from china is a pain lol....

An Arduino (or Arduino Nano).  See link I mentioned in my post above.  I include code for the Arduino program to write the EEPROM.

I didn't find the link on account of being a bit slow sometimes. So I googled it and found these:

https://www.youtube.com/watch?v=phgSPxESXqs

https://www.youtube.com/watch?v=M4-1FqxVJjw

Haven't watched them through yet, but looks like the the right sort of thing. What I am not yet getting is how to push the FV-1 assembler language through the Arduino interface but someone ought to know, right?

Presumably all you lot are running Windows? The problem I had was compiling code. The Spin assembler is windows-only. I found a Python-based thing for Mac OS, but haven't got far with it. I'd like to see a better toolchain for FV-1 on Mac. Anyone else in the same boat?

Windows? Never! Hate it with a vengeance. For all programming related needs, Linux or BSD are oh-so-much more comfortable. And most of those tools should run on MacOS as well, what with it being a BSD derivate and all. The PedalPCB docs for the comming-soon "FV-1 Development Board" have installation instructions for Windows, MacOS and Linux (Ubuntu 18.04, should probably work on any Debian based system). They use a CH341A to talk to the EEPROM, though.

Andy

[Digital Larry]

I've looked at a lot of the examples from the Spin site.  You have to look at the code samples supplied with their "projects" to see a lot of different ones.

I'm no expert, but in general an FV-1 reverb algo starts with 4 short cascaded all pass filters.  These provide a "smearing" effect on transients.  You can adjust the all pass lengths, number in the chain, and coefficient for each one.

Then this enters a "ring" structure composed typically of 2 to 4 comb filter/all pass combinations (I'll call this a link).  A comb filter being just a delay line typically of a longer length, maybe about 0.1 second typically.  The number of all passes in each link is 1 or 2 usually.  Then you can also include high pass and low pass 1 pole filters in each link which adjust the "damping" at high and low frequencies.  You could put shelving filters in those links instead.

The lengths of all pass and comb filters in the Spin examples appear to all be "magic numbers" that I can only conclude came about while Keith Barr was working on the Alesis digital reverbs.  His own writings tilt philosophically towards dialing in sounds "by ear" rather than using any specific formula.  That's great if you have a ton of time!  I've read some things that suggest that reverb delay line lengths should be mutually prime in order to reduce resonances.  It's fairly easy to ask Wolfram Alpha to give you a list of prime numbers between 20 and 5000 which would cover most all pass and delay line lengths used in the reverbs I've seen.

Some of the structures use a multitap delay for "early reflections" and some just tap off after the input cascade of all passes for this.

The ring structure used in most FV-1 reverbs seems a lot like the "Dattorro" reverb.

https://ccrma.stanford.edu/~dattorro/EffectDesignPart1.pdf

I've also made "room" reverbs by just putting 3 delay lines with LPF in the feedback in parallel.  Use a 3-4-5 length ratio.  Put some cascaded all passes in front for extra smearing.

You can see by now that a typical reverb has 20 or 30 parameters that could be adjusted.  It's pretty nutty.  At my age I don't think I'm going to try to figure it out beyond what I've already done.

Because of this complexity, SpinCAD Designer is not really the best tool to experiment with reverb design.  I'd suggest looking at a number of different reverbs in Spin ASM and see how they are the same and how they differ.

[DrAlx]

Regarding the Python FV-1 assembler.  It's called asfv1 and available on github:
https://github.com/ndf-zz/asfv1

I got it working on Linux.

EDIT: I've removed previous comments regarding problems I had with it compared to SpinASM assembler.  I didn't use all the command line options.  I should have used the "-s" option for SpinASM compatibility 

      python asfv1.py -s  MYPROGRAM.spn out.hex

does the trick. I had to comment out lines in the asfv1.py file (i.e. add a #) to all lines at the start that begin with
      from builtins

The output hex file is not what my Arduino program uses though, so I hacked the python code to produce code in C header format instead (which is what it needs).  PM me if you want the hacked program.
... or edit it yourself.  Just replace the "bintoihex" method starting at line 103 with the following routine instead

Code Select Expand


def bintoihex(buf, spos=0x0000, width=4):
    """Convert binary buffer to C header and return as string."""
    c = 0
    olen = len(buf)
    ret = "const unsigned char ROM_00[] PROGMEM = {\n"
    while(c < olen):
        rem = olen-c
        if rem > width:
            rem = width
        l = ""
        for j in range(0,rem):
            nb = buf[c+j]
            l += "0x"
            l += '{0:02X}'.format(nb)
            l += ","
        ret += l + '\n'
        c += rem
    ret += "};\n"       
    return ret


My Arduino program has a single header file containing 8 programs starting with lines as follows

Code Select Expand


    const unsigned char ROM_00[] PROGMEM = {
    ...
    const unsigned char ROM_01[] PROGMEM = {
   ...
    const unsigned char ROM_07[] PROGMEM = {
    ...


so you would have to make that single large header by pasting together 8 smaller ones(from my hacked asfv1.  Either that or edit the Arduino program to load in 8 separate headers for the 8 programs.

[DrAlx]

I have taken my Arduino program, modified the python assembler to make it output header files suitable for it, and zipped it all up for easy(ish) use here:

https://1drv.ms/u/s!AvrH61utWEtEjEHapeiN4xV9bAj0?e=5daUGl
https://1drv.ms/u/s!AvrH61utWEtEjEAmpf8e8doA5GZs?e=56H2UY

The instructions on how to compile a SPN file into a ROM file are in the comments of the arduino program (.ino file).
But here is the info anyway.

The data to be programmed into the 8 spin program slots is defined by the header files "ROM0.h" to "ROM7.h".

Example: To compile the SPN program "myprog.spn" into "ROM5.h" you type the following on the command line:

    python asfv1.py -s myprog.spn ROM5.h

When you've done that for all 8 programs, open the .ino file in the Arduino IDE to write the data to EEPROM (making sure you keep the serial port monitor open in the Arduino IDE so you can see that things got written OK).

A couple of things:

1) Make sure your spn files are encoded in UTF-8.  A lot of the spn files from SpinASM are encoded as UTF-16 and that screws things up.  So if you get one of those files, convert it to UTF-8 encoding using a text editor.

2) I commented out some things at the top of the asfv1.py program. 
The commented out lines are marked by      # Commented out by dralx.
I needed to do that to get it to run OK on my Linux machine.
If you have problems with those being removed, remove the # at the front of each line.

BTW, the guy who wrote asfv1 also uploaded a python disassembler to github.  I used that to investigate the differences between what asfv1 produces and SpinASM.  When differences occur they are all in the least significant floating point bits.
For example, the following line of assembler

          sof   0,0.95

gives  0x00,0x00,0x79,0x8D   in SpinASM and
gives  0x00,0x00,0x79,0xAD   in asfv1.py

which apparently means

          sof   0,0.9501953125

In practice I don't think this sort of difference will give any problem.

[DrAlx]

I have managed to modify the python program to give me exact same assembler as SpinASM for my test program.
Basically, there were lots of expressions to do the float conversions that looked like this
    int(round(   STUFF  ))
Changing them to simply say
    int( STUFF )
gave only one line of assembler different (as opposed to a few dozen).
That remaining difference was down to the "^" symbol which means "read from middle of delay line".
The calculation for the memory location of the middle of the delay line was out by 1 (you could argue that SpinASM was doing it wrong).  Changing that calculation gave identical output.

I will try some more test cases, and maybe fire a mail off to the asfv1 developer.  He may have had some good reason for doing the rounding a different way.