Found DIY Digital Delay with reverse based on Arduino Nano

[telebiker]

Was digging the internet and found pretty interesting article: https://create.arduino.cc/projecthub/CesarSound/echotrek-digital-delay-echo-audio-effects-with-arduino-b017a2
Basically that's digital delay. The cool thing about it is that it has reverse mode. I know that there are people interested in DIY reverse delay (including me), so this might be an option.

[Digital Larry]

Let's just talk about reverse delay for awhile.  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.

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.

DL

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

[potul]

The way I have seen it done is using one single buffer, but the read pointer moves forward at double speed. This way the read pointer gets the reversed sample, but it will  take also half of the time to reach the end of the buffer and start over.
So at the end you need double amount of RAM for the same delay time.

Good point on the repetitions... never heard a reverse delay with feedback.. but I guess it would be really sick.

[pruttelherrie]

This one plays back in reverse: (boolean 'rev' = reverse mode)

Code Select Expand


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];
}


How does the XP-300 Space Station do the reverse modes? The "stop-and-reverse-by-treadle" effect is pretty cool! Unfortunately my hand-foot-synchronisation is beyond bad for this kind of stuff :/

[Digital Larry]

The way I have seen it done is using one single buffer, but the read pointer moves forward at double speed. This way the read pointer gets the reversed sample, but it will  take also half of the time to reach the end of the buffer and start over.
So at the end you need double amount of RAM for the same delay time.

Boy... I am just not able to visualize that.

I double checked my Will Pirkle "Designing Audio Effect Plugins in C++" 2nd edition book and he does not go into it.  I asked on his forum, let's see what he says.

[Digital Larry]

This one plays back in reverse: (boolean 'rev' = reverse mode)

Code Select Expand


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];
}


How does the XP-300 Space Station do the reverse modes? The "stop-and-reverse-by-treadle" effect is pretty cool! Unfortunately my hand-foot-synchronisation is beyond bad for this kind of stuff :/

OK 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.  Have you run it?  Seems like it would be glitchy.

I'm also a little confused about the need for the second buffer.  Since you copy the data from the first buffer to the second one all the time, I don't see how the second buffer changes anything.

[potul]

The way I have seen it done is using one single buffer, but the read pointer moves forward at double speed. This way the read pointer gets the reversed sample, but it will  take also half of the time to reach the end of the buffer and start over.
So at the end you need double amount of RAM for the same delay time.

Boy... I am just not able to visualize that.

I double checked my Will Pirkle "Designing Audio Effect Plugins in C++" 2nd edition book and he does not go into it.  I asked on his forum, let's see what he says.

Sorry, I was talking in FV-1 terms (the pointers don't move, but the memory shifts). In normal terms:
Circular buffer. Write pointer moves to the left, read pointer moves to the right. They will cross 2 times per buffer length. Glitchy crossing probably, so you may need some kind of smoothing...

[telebiker]

I'd call this "fake reverse delay - envelope only".

That's an interesting thought. Reverse delay term can be defined differently and pedal manufacturers could mean whatever they want using this term. For example, in this delay reverse mode sounds like fake:
https://youtu.be/2f8HD8r3vsY?t=343

[telebiker]

And Danelectro Back Talk sounds like not fake:
https://www.youtube.com/watch?v=Lc1zvoU6tmg

[Digital Larry]

And Danelectro Back Talk sounds like not fake:
https://www.youtube.com/watch?v=Lc1zvoU6tmg

I'm not convinced by the Danelectro, actually.  Not that I am the arbiter of truth or reality here or anything.  Some of the licks sound pretty much the same, just with the enveloping on them.  Say, at about 3:45.

He talks about "NOS delay chips" used in the original.  OK, we don't know what that means, and I didn't review further to see if the pedal uses BBDs but I'll just go on record saying I think true reverse delay with a regular BBD is not going to be possible.

I just got an HX Effects unit yesterday, I'll try to see what it does.

DL

[vigilante397]

He talks about "NOS delay chips" used in the original.  OK, we don't know what that means, and I didn't review further to see if the pedal uses BBDs but I'll just go on record saying I think true reverse delay with a regular BBD is not going to be possible.

Obviously not true reverse delay, but if someone talks about reverse delay with BBD they're likely talking about something like the EHX Attack Decay, which is a "tape reverse simulator."

[Digital Larry]

Here's the results of the reverse delay in the Line6 HX effects.

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

#1 When you play a note there is always a pause before you hear what you played.  In the case where you were using a single buffer with pointers sweeping in opposite directions, the actual amount of delay between what you played and what comes out would always be changing between 0 - max. 

#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.

Now sure, as long as it sounds cool, who cares how it works, but just to be extra pedantic about it:
- technical curiosity and why the heck are we here, anyway?
- not all reverse delays appear to be created the same, caveat emptor/creator
- other than saying "wow, that's cool", I still find it a challenge to strategize "working with the effect" to create a desired result.  On a regular delay you can lock in with it and play the same thing , or harmonize, or alternate chords with lines, or play staccato to build up distinct rhythms etc.  Maybe I'll play with it a bit more to explore the possibilities, as my conclusion here is based on about 5 minutes with it.

DL

[pruttelherrie]

This one plays back in reverse: (boolean 'rev' = reverse mode)

Code Select Expand


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];
}


How does the XP-300 Space Station do the reverse modes? The "stop-and-reverse-by-treadle" effect is pretty cool! Unfortunately my hand-foot-synchronisation is beyond bad for this kind of stuff :/

OK 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.  Have you run it?  Seems like it would be glitchy.

I'm also a little confused about the need for the second buffer.  Since you copy the data from the first buffer to the second one all the time, I don't see how the second buffer changes anything.

Oh, I think you misunderstood: that was the code of the original post, not mine.

I too am confused about that second buffer.

[Digital Larry]

Oh, I think you misunderstood: that was the code of the original post, not mine.

I too am confused about that second buffer.

Sorry, didn't mean to sound accusatory.   
I figured that since you copied and pasted it though, you should take responsibility for leading me astray.   

One of my remaining questions is whether the enveloping has any relationship to the guitar's dynamics, e.g. like a Slow Gear, or if it just follows the delay buffer wraparound (in the case where audio is really being reversed).