SpinCAD reverse delay

[pbrommer]

I know that the reverse delay block exists and works nicely, but it chews up so much delay memory and lacks ability to control (that I can understand with my limited knowledge).


If there are suggestions on how to tackle making it sound just a bit nicer, that would be awesome. I'm open to other ideas. I guess I'm trying to help myself and hopefully help others.

Patrick

[Digital Larry]

Hi Patrick,

You sure do know how to find the sensitive parts quickly!  Reverse delay block was supplied by a user, I can't remember who it was at the moment.  Yeah I think it chews up the entire memory.  I'll put it on my list of things to look at (which is looking like it's going to last me a good long while)!  Meanwhile, anyone who wants to see if they can make the "reverse delay" block more general purpose, you have my full blessing!   

Here's the SpinCAD Builder code:

Code Select Expand


@name "Reverse Delay"
@color "0x7100fc"
@audioInput input Input
@audioOutput output Output
@audioOutput output2 Output2
@controlOutput ramp Ramp
@controlOutput ramp2 Ramp2
@controlOutput xfade Xfade

mem delay 32767
equ output reg0
equ output2 reg3
equ ramp reg1
equ ramp2 reg4
equ xfade reg2

@isPinConnected Input
skp run, loop
sof 0, -0.25   ;clear acc and set -0.25
wrax rmp0_rate, 0   ;ramp rate = -.25, clear to 0
wrax RMP0_RANGE, 0 ;ramp range= 0

loop:

; sof 0,0      ;clear acc

rdax input, 1.0    ;read left adc
wra delay#, 0.0    ;write to delay ram and clear
cho rdal, rmp0    ;get ramp lfo
wrax addr_ptr, 1.0    ;write data at delay ram address
wrax ramp, 1.0 ; just for debugging
sof 1.0, -0.25
absa
sof -2.0, 0.25
sof -2.0, 0
sof -2.0, 0
sof -2.0, 0
sof -2.0, 0
sof 0.5, 0.5
wrax xfade, 0.0 ; just for debugging
;-----------------------
rmpa 1.0       ;read data at delay ram address (ADDR_PTR) 1.0
wrax output, 0.0
;-----------------------
rdax ramp, 1.0
sof 1.0, -0.125
wrax ramp2, 1.0
skp  gez, secondhalf  ; if > zero then past half way, waveform already in position as starting from 0
sof 1.0, 0.325 ; otherwise shift it back 0.125 to compensate for previous offset and 0.25 more
secondhalf:
wrax addr_ptr, 0.0
rmpa 1.0
wrax output2, 0.0

@endif

@setOutputPin Output output
@setOutputPin Output2 output2
@setOutputPin Ramp ramp
@setOutputPin Ramp2 ramp2
@setOutputPin Xfade xfade


DL

[pbrommer]

I'm here just to find all of the soft spots! 

Actually, I'm just trying to make some weirder stuff, a la DRolo, who has some cool stuff. I'm in a pedal build mode (switching between amps, guitars, and pedals) and having a great time. Hopefully I can stumble on something interesting.

Just hoping to find a way to do a reverse delay with a reverb -- that would be neat (I know Flamma has something like that on one of their pedals and it's kind of neat).

[potul]

Reverse delay with reverb is a stretch goal with the FV1.
Building a nice sounding reverse delay without glitches takes quite a lot of instructions and most RAM. Not much left for a reverb.
If you are more into glitchy reverse delay, then maybe you can make it.

[pbrommer]

I found a couple reverse delay patches: one by Knut and one by igorp.

igorp code:

Code Select Expand

; afx_reverse_delay.spn
; reverse-delay by igor@shift-line.com 2018
; simplified part of A+ Paradox delay
; https://github.com/igorpie/Spin-FV-1/blob/master/afx_reverse_delay.spn

equ size  32767
mem mem_dly size

equ FC0  0.98 ; tails filter

equ out_fwd reg0 ; classic delay out
equ out_bwd reg1 ; reverse delay out

EQU f1 reg3 ; tails LPF
EQU f4 reg4 ; delay loop HPF
EQU f5 reg5 ; x-fade envelope (LPF)

equ fbk reg6 ; feedback

EQU cf1 reg10 ; cross-fade
EQU th1 reg11   ; time threshold1 before step
EQU th2 reg12 ; time threshold2 after step

equ ad_fbk reg14 ; current address pointer fbk of forward delay.
equ ad_reg  reg15 ; current address reverse

EQU temp reg16

equ f2 reg31

; equ pot_unzip pot0 ; bit crush value
equ pot_delay    pot2
equ pot_feedback  pot1

skp run , start
clr
wrax ad_reg , 0
start:

;{ controls smooth
;}

;{ DELAY
ldax fbk
rdax adcl,   1.0/2 ; classic forvard delay
wra mem_dly , 0

;{{ dly
or size*256
mulx pot_delay ;
wrax ad_fbk , 1 ; save for reverse delay starting point
wrax addr_ptr,  0
rmpa 1 ; read delayed value
;}}     

;filter HPF
rdfx f4, 0.003202 ; HPF remove highs to avoid constant voltage accumulation. dirty way WRHX
wrax f4 , -1
rmpa 1

; dummy LPF for repeats
RDFX f1 , FC0 ; LPF fbk
WRAX f1 , 1
wrax out_fwd , 1 ; output of forward delay

      mulx pot_feedback ; feedback value 12 +/-
      mulx pot_feedback

sof 1.1 , 0
wrax fbk , 0
;} end delay

;{ REVERSE read
or 0xFFFE00 ; move pointer of reverse delay
rdax ad_reg , 1 ; reverse ptr -= 2
skp gez , ok1
ldax ad_fbk ; load initial reverse pointer value by forward delay value
wrax ad_reg , 1
ok1:
and 0x7FFFFF
; wrax dacr , 1 ; *** debug

wrax ad_reg ,  -1    ; (+1 = octave up , -1 = reverse read)
wrax addr_ptr,   0   ; reverse read pointer

rmpa 1 ; read reverse delay
mulx f5 ; do x-fade , may be one more mulx needed for smooth
wrax out_bwd , 0
;}

; ********************************
;    prepare x-fade envelope
; ********************************
; fade envelope
;{ ; compare reverse pointer address with (reverse - 256 ) and (reverse + 256).
rdax ad_reg , -1
and 0x7FFFFF
; wrax dacl , 1 ; *** debug
wrax temp , 1 ; temp 2 == LFO
; (A=LFO value)

; (ramp begin)
sof 1 , - 1/256
skp gez , gez1
clr
wrax th1 , 0 ; dirty step down (zero volume)
skp run , gez2
gez1:
sof 0 , 0.998 ; (volume normal)
wrax th1 , 0
gez2:

; (ramp end)
ldax temp ; mostly the same
sof 1 , - 255/256 ;
skp gez , gez3
sof 0 , 0.998
wrax th2 , 0
skp run , gez4
gez3:
clr
wrax th2 , 0
gez4:
ldax th2 ; Acc = sum of fades (if before or after step is zero, result = zero)
mulx th1

rdfx f5, 0.0006*64 ; capacitor for declicking (smooth angles of square) , |_| will be \/
wrax f5 , 0
;}
;{ ========= OUT ==============
rdax out_bwd , -2
wrax dacl , 0 ; ***
;}
eof:

Knut code:

Code Select Expand

; Reverse Delay
; Knut Helle
; June 2017
;
; POT0 = Reverse segment length
;
equ   length   32767    ; Buffer length
equ   inc   512   ; increment
;
mem   echo   length   ; Delay Buffer
;
equ   addr   reg0   ; rmpa / addr_ptr addres
equ   size   reg1   ; delay buffer size value
;
; Startup Initialization ################################
;
skp   RUN,   loop
clr
wrax   addr, 0      ; Clear reg on startup
loop:
;
; Reset address pointer ################################
;
sof   0, 0.1      ; +0.1
rdax   POT0, 0.9   ; Pot / 'size' range 0.1 to 1
wrax   size, 0      ; write to reg, clear
;
clr   
or   length*256   ; add max delay addres   ( or 8388352 )
mulx   size      ; * size variable
rdax   addr, -1      ; subtract current addres
;
skp   GEZ, reset   ; if NEG (addr > max addres)
clr
wrax   addr, 0      ; Reset addr ( = 0 )
reset:
;
; Set address pointer    USES '-1' instead og 1.0 for better accuracy ###################
;
clr         ; acc = 0
or   inc      ; add increment (+)
sof   -1, 0      ; -> (-)
rdax   addr, -1      ; add addr (-)
sof   -1, 0      ; -> (+)
wrax   addr, -1      ; write to addr, then (-)
sof   -1, 0      ; -> (+)
wrax   ADDR_PTR, 0   ; write to addr_ptr (+), clear acc
;
; Audio In/Out   ###########################################
;
ldax   ADCL      ; Get input
wra   echo, 0      ; Write it to the head of the delay buffer
rmpa   1      ; Read from memory (set by ADDR_PTR)
wrax   DACL, 0      ; ACC-> DAC

Just wondering thoughts on if either looks "better" than the other. Just trying to get some small FV-1 pedals going for myself to have around for adding space to my playing. You are all awesome!

Patrick

[Digital Larry]

Cool.  The challenge with some of these things (and I sense it here as well) is that there are patches you can make in SpinASM that take advantage of certain assumptions, such as memory buffer starts at zero, or all memory is used, etc.  With SpinCAD, RAM access is handled much differently than you normally do writing code by hand, because everything needs to be relocatable to any starting address and scalable to any length.  I'll take a look at these anyway but they both look like they allocate the entire RAM buffer.

I mean, that said, SpinCAD is not the be-all end-all for all possible things.  It's just a lot easier to get into than SpinASM for what it does do well.

DL

[potul]

Just wondering thoughts on if either looks "better" than the other. Just trying to get some small FV-1 pedals going for myself to have around for adding space to my playing. You are all awesome!

Patrick

The igorp one is the best I could find. But it's quite lengthy, not sure if it's going to fly to transform it into a spincad block. There is a lot going on there.

[pbrommer]

I wasn't too worried about the reverse delay being in SpinCAD. I'll probably just work with the igorp reverse delay and have someone burn it to an EEPROM. No use overworking yourself for just me in SpinCAD.

[Cybercow]

. . . . .

Meanwhile, anyone who wants to see if they can make the "reverse delay" block more general purpose, you have my full blessing!   

Here's the SpinCAD Builder code:

Code Select Expand


@name "Reverse Delay"
@color "0x7100fc"
@audioInput input Input
@audioOutput output Output
@audioOutput output2 Output2
@controlOutput ramp Ramp
@controlOutput ramp2 Ramp2
@controlOutput xfade Xfade

mem delay 32767
equ output reg0
equ output2 reg3
equ ramp reg1
equ ramp2 reg4
equ xfade reg2

@isPinConnected Input
skp run, loop
sof 0, -0.25   ;clear acc and set -0.25
wrax rmp0_rate, 0   ;ramp rate = -.25, clear to 0
wrax RMP0_RANGE, 0 ;ramp range= 0

loop:

; sof 0,0      ;clear acc

rdax input, 1.0    ;read left adc
wra delay#, 0.0    ;write to delay ram and clear
cho rdal, rmp0    ;get ramp lfo
wrax addr_ptr, 1.0    ;write data at delay ram address
wrax ramp, 1.0 ; just for debugging
sof 1.0, -0.25
absa
sof -2.0, 0.25
sof -2.0, 0
sof -2.0, 0
sof -2.0, 0
sof -2.0, 0
sof 0.5, 0.5
wrax xfade, 0.0 ; just for debugging
;-----------------------
rmpa 1.0       ;read data at delay ram address (ADDR_PTR) 1.0
wrax output, 0.0
;-----------------------
rdax ramp, 1.0
sof 1.0, -0.125
wrax ramp2, 1.0
skp  gez, secondhalf  ; if > zero then past half way, waveform already in position as starting from 0
sof 1.0, 0.325 ; otherwise shift it back 0.125 to compensate for previous offset and 0.25 more
secondhalf:
wrax addr_ptr, 0.0
rmpa 1.0
wrax output2, 0.0

@endif

@setOutputPin Output output
@setOutputPin Output2 output2
@setOutputPin Ramp ramp
@setOutputPin Ramp2 ramp2
@setOutputPin Xfade xfade


DL

I am by no means adept with SpinASM and can manage to navigate SpinCAD well, but it occurs to me that perhaps by reducing the value of the  "mem delay 32767" line to a lower value, possibly freeing some resources to add pots back in. TBH, I'm not sure what value is credible or if that would even work.

[Digital Larry]

Unfortunately, freeing up RAM space does nothing to allow for more instructions.   

[Cybercow]

Unfortunately, freeing up RAM space does nothing to allow for more instructions.   

Thanks for that Larry. Your point makes sense.

Now that I've put some PC time into the the OP's SpinCAD Design test for that Reverse Delay, and testing a few variants of the exported SpinASM files in a my FV-1 Development board test bed, I can see that the "Reverse Delay" SpinCAD block has no "Inputs". Those three circles on the right side of the Reverse Delay SpinCAD block are designated as outputs only. I'm guessing those three out puts need only be flipped to act as "Inputs". And unfortunately, I have no idea how to do that. No clue why a reverse delay would want three such outputs.

Currently, the "Reverse Delay" SpinCAD block has no 'Control Panel' and the three output access points are designated as "Ramp", "Ramp 2" & "xfade".

[Digital Larry]

Thanks for that Larry. Your point makes sense.

Now that I've put some PC time into the the OP's SpinCAD Design test for that Reverse Delay, and testing a few variants of the exported SpinASM files in a my FV-1 Development board test bed, I can see that the "Reverse Delay" SpinCAD block has no "Inputs". Those three circles on the right side of the Reverse Delay SpinCAD block are designated as outputs only. I'm guessing those three out puts need only be flipped to act as "Inputs". And unfortunately, I have no idea how to do that. No clue why a reverse delay would want three such outputs.

Currently, the "Reverse Delay" SpinCAD block has no 'Control Panel' and the three output access points are designated as "Ramp", "Ramp 2" & "xfade".

Any block that looks like that simply means that I am bringing internal signals out so I can look at them on the scope or level viewer to see what they are doing. 

[Cybercow]

Any block that looks like that simply means that I am bringing internal signals out so I can look at them on the scope or level viewer to see what they are doing.

That's a cool trick! I hadn't considered that.