Please consider registering

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —

— Match —

— Forum Options —

Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Strategies for reverse delay?
February 11, 2021 - 3:42 pm
Member Since: December 24, 2020
Forum Posts: 7
sp_UserOfflineSmall Offline

Hi Will, sorry but this is a question about something that isn't in the book... but I did look!

It seems like there are different implementations and they seem to require some tricks.

I'm pretty sure I have tried some that didn't really reverse the signal, but they applied a long attack/short decay envelope over a normally delayed signal. One way to tell is to do some descending glissandos. When you hear them back, do they go up or down? I'd call this "fake reverse delay - envelope only".

If you use a looper, you can record 30 second or whatever, hit the loop button to start playback, and then hit "reverse". Well the whole thing was recorded already, so just play it back in the reverse direction - fine.

But, "reverse delay" seeks to create "reverse sounding" delay sounds more or less in real time, so this implies that you will be recording and reversing shorter segments of audio. If you just use one buffer, you could record for e.g. 500 msec then play that back. This would put 500 msec gaps in everything. I guess you could use two buffers side by side and be recording into one while you read out from the other one.

I'm pretty sure you cannot effectively use a single buffer for this, because you'd be writing over the thing you were trying to play back.  BUt maybe I'm wrong?  Also you will probably have to fade playback of the buffer ends as they will wrap around to some completely different signal.  I know there is some FV-1 reverse delay, I think I even put it into SpinCAD (someone else provided it) but I never sat down to figure out how it works.

Also - if a signal goes through a reverse delay with feedback, does every other pass sound normal, or what?



February 13, 2021 - 10:50 am
Member Since: December 24, 2020
Forum Posts: 7
sp_UserOfflineSmall Offline

OK, strictly speaking this is not a question about the book, and more likely than not htis is the sort of thing Will gets paid extra for.  I did some tests with my Line6 HX Effects Reverse Delay block and had a little discussion over at diystompboxes.com where DSP is more in the realm of Arduinos and the FV-1 dedicated chip.

A guy supplied this Arduino code (it appears to be lacking initialization and has some other odd features, but just for reference):

void delay_sound() {
  i = i + 1; if (i > d_time) i = 0;
  delay_data[i] = val;
  if (i == d_time) j = 0;
  delay_data_1[i] = delay_data[i];
  j = j + 1; if (j > d_time) j = 0;
  if (!rev) d_val = delay_data_1[j];
  if (rev) d_val = delay_data_1[d_time - j];

Looking at this really quickly, it looks like
a) There's a circular buffer
b) every sample there is a new value written, the index increments and wraparound is performed
c) When the write pointer reaches the end, the read pointer offset is set to 0. So I don't know what the read pointer offset is before that.
d) Ok, so let's assume now that you just have one pointer going this way and one going that way and they meet in the middle every time. So, when the read pointer is between 0.5 and 1.0 of the buffer length, it's reading the previous pass' data.
e) At 0.5, the read and write pointers are in the same place but going in different directions. So the delay between read and write at that exact moment is zero.
f) I guess, since we know exactly where the meeting point is, that enveloping can be done without having to analyze the signal at all.

I do not see any enveloping in the code above. Seems like it would be glitchy.

I'm also a little confused about the need for the second buffer. Since the routine copies the data from the first buffer to the second one all the time, I don't see how the second buffer changes anything.  No need for explanations, it's someone else's code, and it probably works.

Another attribute of this implementation is that the amount of time that elapses between your played note and it first coming back varies between almost immediately (when both pointers pass each other in the middle of the buffer) to the full delay length (just prior to that point). 

Here's what I perceive on the line6:

Let's suppose I played two notes, D to C, which will be represented by "beep-boop"

#1 the amount of time that elapses between your played note and it first coming back varies between almost immediately and some longer amount of time.

#2 The first thing you hear is often a clipped off reversed version of what you played, followed by the full phrase. e.g. "eeb .... poob-peeb", but it is not the same each time.

#3 with repeats turned up, you simply hear "poob-peeb" repeated over and over.

So, it looks like there is some block that does "reversing" and then it just goes into a normal delay with feedback/tone/etc.

The first note getting cut off sometimes leads me to believe that there is enveloping going on around the glitch point, which is probably slow attack/fast release (so to speak) linked simply to where we are in the buffer with the two pointers.  I can't tell if there is any dynamic gating on top of that but I don't think so. 

What's interesting about this is that there seems to be a certain amount of fakery going on.  There are some BBD-based "reverse tape emulation" pedals around but AFAIK there is no way to reverse the signal coming out of a BBD, so I'm guessing they use dynamics to trigger a long attack/short delay which then goes into a normal delay line.  So, if you can get somewhat reverse-sounding effects by just doing enveloping, you can make that even better by actually reversing the signal and also applying the envelope.  My point here is that some of the long attack/short decay will be coming from the reversed notes that you actually played, and some of it will be coming from the envelope generator. 

This is one of those weird effects where it's not quite so straightforward to play along with it, as what it does in one moment differs from the next.  I found I could sync what I was playing to the effect, but I kinda had to tap my foot to do it, rather than just listening to the output.  You can get the beat by listening to the repeating bit.

I applied the "glissando test" to the line6.  Here, you turn the delay feedback all the way off and do a slow descending glissando on your guitar.  What you hear is a series of short rising glissandi, however on the whole they are still going down.  This corresponds to the model of cutting a recording tape into short bits and reversing each one, then splicing them back together.

All of this is just guesswork, so if anyone wants to correct me or add some info based on real knowledge, that would be cool.  thx!



W Pirkle
March 11, 2021 - 12:58 pm
Member Since: January 29, 2017
Forum Posts: 573
sp_UserOfflineSmall Offline

The reverse delay always requires pre-buffering; a good place to start is a block diagram of a commercial algorithm. 

Go to page 182 here:


It is the Korg Triton reverse delay (the same algorithm has been used for years and years) that shows the waveform image and the different modes. As a bonus, it also lists the GUI parameters and their limits. 

Hope that helps - reverse algorithms are always going to suffer because of the initial hit you take as you can't reverse what has yet to be captured. When I assign this as a class project, I usually tell the students to use a double buffer system which is probably what you hear on the Line 6 stuff. 


Forum Timezone: America/New_York

Most Users Ever Online: 152

Currently Online:
6 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Chaes: 51

Skyler: 48

Derek: 46

Frodson: 45

Peter: 43

TheSmile: 43

clau_ste: 39

jim: 34

JimmyM: 33

Gwen: 32

Member Stats:

Guest Posters: 1

Members: 698

Moderators: 1

Admins: 5

Forum Stats:

Groups: 13

Forums: 41

Topics: 757

Posts: 2895

Newest Members:

lance, Mistahbrock, Jas, Rowan, sojourn, fabhenr, rg1, Niklas, Wutru, Tim Campbell

Moderators: W Pirkle: 573

Administrators: Tom: 74, JD Young: 80, Will Pirkle: 0, W Pirkle: 573, VariableCook: 3