Looper's Delight Archive Top (Search)
Date Index
Thread Index
Author Index
Looper's Delight Home
Mailing List Info

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Date Index][Thread Index][Author Index]

Re: Reverse Delays - how do they work?



hi Rainer.

My favourite implementation of reverse (other than the loop situation) is
the one on the EH SMM + Hazari.
The pedal does nothing till you hold down the footswitch, then it plays 
back
what you just did (for up to 6s).
The regular reverse delay on the SMM( as you will have noticed) has some 
kind 
of a trigger combined with the programmable delay length, but I didn't 
figure
it out yet exactly.

The type of reverse with continuous record and play in opposite directions 
can be got out of the Behringer Virtualizer, using the "Sampler" patch.
It's glitchy when the 2 "heads" cross, but gives an idea of the effect.

Most obvious implementation would be a kind of ducking delay, which waits 
for you
stop playing then starts playback.

andy butler  

  

Rainer Thelonius Balthasar Straschill wrote:
> I just spent some time thinking about reverse delays, which several 
>boxes do
> offer (among them, to take a few devices used often among loopers, the 
>Line6
> DL4, the TC Electronics D2, the Boss DD20 and the EH SMM w/ Hazari).
> 
> So here's my take (without listening to these devices) what is possible 
>how
> to implement that effect - and I'd like your ideas what are the preferred
> implementations, and wheter there are other ways to reach this.
> 
> In a normal delay, it's rather simple: taking feedback aside for one 
>moment,
> and assuming an ideal delay (i.e. what goes in does come out sometime
> later), it's like a conveyor belt. You put the things (your playing) on 
>one
> side, and after a finite (and constant) time, it comes out at the other 
>end.
> Another (more audio-tech) analogy is the endless tape, where you record, 
>the
> tape goes round, gets played back and immediately recorded again.
> 
> This approach will not work if we want a reverse delay, because the 
>things
> need to come out in different order than the order they were put in. So 
>how
> can you do it?
> 
> APPROACH ONE: Turning around
> Again taking the conveyor belt analogy, after the conveyor belt is full, 
>we
> can simply turn it around and reverse the direction of travel. If we do
> feedback in a normal way (i.e. part of the output gets put on the 
>conveyor
> belt again), we will end up with the contents playing back
> reverse-forward-reverse-... etc.
> The problem here: how do we know when to turn around the conveyor belt? 
>If
> we just do it after the belt is full (i.e. it has run from beginning to
> end), our LTI system turns into being non-time-variant and for that 
>reason,
> very hard to guess in its behaviour by the user. We could use a trigger 
>to
> tell the delay when we start to fill the belt. With that, the delay 
>between
> the trigger and the perceived beginning of delay playback is just the 
>delay
> length.
> I believe (due to the availability of a trigger threshold), this is the 
>way
> the D2 works.
> 
> APPROACH TWO: Running two ways
> I will take the endless tape analogy here. Assume the tape is stationary 
>and
> the heads are moving, and the behaviour stays the same (according to
> Einstein). Now ignore for one moment the problem of heads getting into 
>each
> others' way. Now let's move the recording head in one direction and the
> playback head in the other direction. Having feedback according to the
> original meaning of the word (feeding back the output to the input) would
> also give us the reverse-forward effect. However, we can replace that 
>with
> an approach which only erase the tape partially. With that, everything in
> the delay output is always reverse, and never reverse-of-reverse.
> Note that with that approach, the perceived length of the delay is cut in
> half.
> Also, the "when to turn the belt" problem gets replaced by the "when do 
>the
> heads meet" problem.
> Due to the fact that in the DL4, the reverse delay time is half that of 
>all
> other delays, I believe it uses this approach.
> 
> 
> Now...what other approaches are there? Is there one that is 
>time-invariant
> without a trigger (and causal)? Is there another possibility? Any 
>thoughts?
> Are you using reverse delays at all?
> 
>       Rainer
> 
>