Fv-1 and tap

[Matthewseffects]

Is it possible to do a micro controller that controls a digital pot accurately enough on the fv-1 to control tap timing or is it best to use one of the digital inputs on the fv-1 as a switch input and do the time control inside the fv-1?

Anyone have experience doing this?

[Digital Larry]

I've seen a couple tap algorithms which sense the pot inputs.  Those work well for delay as it just counts up once each sample period at 32 kHz and you can use this value directly to index the delay RAM (well, after you multiply it by 256).  Far as the other approach I have not tried it so can't tell but my guess is that it could work OK.

Slacker's code (which is around here somewhere) has an example tap-tempo delay as one of the patches.

DL

[Ice-9]

Slackers code works very nicely for tap tempo, if the program you want tap tempo on uses all the 127 clicks or thereabouts then you will probably need to control the tap outside the FV-1.

[Matthewseffects]

I'm trying to find slackers post about it, anyone know where it is?
or can someone tag him on this would love to ask him.

[Digital Larry]

His pedal was called "babelfish":

http://www.diystompboxes.com/smfforum/index.php?topic=104291.msg986526;topicseen#msg986526

[slacker]

Here's the code, this is an example of a tap tempo delay, the tap tempo part is everything down to ENDTT:. The taptempo register contains a value between o and 1 that corresponds to the tap tempo, in theory you can scale or manipulate this in other ways to control anything you like.

There's more about it here http://www.spinsemi.com/forum/viewtopic.php?t=302&start=0&postdays=0&postorder=asc&highlight=

Code Select Expand


;tap tempo delay
;mono input (ADCL) mono output (DACL)
;a 0 - 0.99 square wave at the tap tempo rate is send to DACR. This can be used to flash a LED using a suitable driver.
;Pot 2 is used as a tap tempo switch input. This should be a momentary switch, transition can be high to low or low to high.
;see guitar amp application note for examples of switch hookup.
;pot 0 = feedback
;pot 1 = delay level

;set up registers and equates

equ  db reg0      ;debounce
equ  mom reg1      ;momentary output of switch +1 high, -1 Low
equ  latch reg2      ;latched output of switch +1 high, -1 low
equ ramp reg3      ;current value of rmpo, scaled to 0 to 1
equ taptempo reg4   ;taptempo value, 0 to 1
equ fback reg5      ;feedback
equ delayout reg6      ;delay output
equ clip reg7      ;clipping
equ led reg8      ;taptempo LED

equ count 0.01      ;debounce counter
equ delaytime 330      ;initial delay time in milli seconds

mem delay 32767

skp run,START
wldr rmp0,0.064,4096   ;set up rmp0
wldr rmp1,0.064,4096   ;set up rmp1
sof 0,0.99     
wrax latch,1      ;set latch = 1 high
wrax led,0      ;set led = 1 high
sof 0,delaytime/1000   ;set initial delay time
wrax ramp,0

START:

;Switch Debouncing and pot filtering work around

ldax   pot2   ;read pot2
sof 1,-0.5   ;level shift to -0.5 to 0.5
skp neg,DOWN   ;if negative jump to DOWN
ldax db      ;else high, read db
sof 1,count   ;add count
wrax db,0   ;write new value to db
skp zro,ENDDB   ;jump to ENDDB
DOWN:
ldax db      ;read db
sof 1,-count   ;deduct count
wrax db,0   ;write new value to db

ENDDB:

;latching switch, falling edge triggered flipflop
;Output of debounce routine of < -0.9 is low, > 0.9 is high, values in between
;are ignored and the switch does nothing, Schmitt trigger action.


ldax db         ;read db
absa         ;get absolute value
sof 1,-0.9      ;deduct 0.9 so only values < -0.9 or > 0.9 give a positive result
skp neg,ENDSWITCH   ;if negative then jump to ENDSWITCH
ldax db         ;read db
sof 1,-0.9      ;deduct 0.9
skp neg,LO      ;if negative jump to LO, output of debounce is low
sof 0,0.999      ;else output of debounce is high
wrax mom,0      ;set mom to 1 (high)
skp zro,ENDSWITCH   ;jump to ENDSWITCH
LO:
ldax mom      ;read mom
skp neg,ENDSWITCH   ;if it's negative then debounce was already low last time so do nothing, jump to ENDSWITCH
sof 0,-0.999      ;else mom was high last time so switch has only just been pressed (falling edge)
wrax mom,0      ;set mom to -1 (low)
ldax latch      ;read latch
sof -1,0         ;invert, high becomes low, low becomes high
wrax latch,0      ;write to value to latch

ENDSWITCH:

;tap tempo, uses rmp0 as a 1 Hz rising ramp, runs whilst latch is low and is sampled and held when latch is high

ldax latch      ;read latch
skp neg,LOW      ;if negative jump to LOW
jam rmp0      ;else latch is high, jam rmp0 (reset to 0)
ldax ramp      ;read ramp, will contain last value of rmp0 before latch went high   
wrax taptempo,0      ;write to taptempo
skp zro,ENDTT      ;jump to ENDTT
LOW:
sof 0,0.064     
wrax rmp0_rate,0      ;set rmp0 rate to 1Hz
cho rdal,rmp0      ;read value of rmp0
sof -2,0.999
sof 1,0.001      ;level shift to 0 to 1 rising ramp
wrax ramp,1      ;write to ramp
sof 1,-0.999      ;deduct 0.999 from ramp     
skp neg,ENDTT      ;if answer is positive then second tap hasn't happened with 0.999 ms of first         
ldax taptempo      ;so keep last value of taptempo
wrax ramp,0     
sof 0,0.999      ;and reset latch high
wrax latch,0
ENDTT:

;Taptempo rate indicator, creates a square wave at the tap tempo rate
sof 0,0.064     
wrax rmp1_rate,0      ;set rmp1 rate to 1Hz
cho rdal,rmp1      ;read value of rmp1
sof -2,0.999      ;level shift to 0 - 1 rising ramp
sof 1,0.001
rdax taptempo,-0.5   ;deduct half of the taptempo value
skp neg,ENDLED      ;if negative skip to ENDLED
jam rmp1      ;else reset ramp1
ldax led         ;and invert value of led register, creates square wave at taptempo rate
sof -1,0
wrax led,0
ENDLED:

;delay

clr
rdax fback,0.95      ;read feedback register, scaled to 0.95%
rdax adcl,1      ;mix with input from ADCL
wra delay,0      ;write to head of delay
ldax taptempo      ;read taptempo register
wrax addr_ptr,0      ;write to delay address pointer
rmpa 1         ;read from delay address set by pointer
wrax delayout,1      ;write to delayout register

mulx pot0      ;mulx with pot0, feedback level control
wrax clip,-0.33333   ;soft clip, using cube distortion snippet
mulx clip
mulx clip
rdax clip,1
wrax fback,0      ;write to feedback register

rdax delayout,1      ;read delayout register
mulx pot1      ;mulx with pot1, delay level control
rdax adcl,1      ;mix with input from ADCL
wrax dacl,0      ;write to DACL

ldax led         ;read led register
wrax dacr,0      ;write to DACR, flashes LED attached to DACR


[Matthewseffects]

Slacker I'm wanting to work on a retail product, I definitely don't want to just take advantage of free code. Would you be interested in consulting a little for a fee?


Sent from my iPhone using Tapatalk

[slacker]

PMed you.

[Matthewseffects]

Thanks!


Sent from my iPhone using Tapatalk

[bartimaeus]

I am quite familiar with slacker's tap code, but losing two of the FV1's pot inputs for time is pretty frustrating (even if you do feedback in the analog realm). Frank posted some code which set the delay time from a clock input, but it also used two of the pot inputs to set the delay time.

It seems much better to use microcontroller to send a voltage based on either a voltage pot's value or a tapped in value. It seems like the Keeley Delay Workstation does this. Has anyone on this forum tried it? Perhaps one of those Atmel chips could do the trick? I'm not sure if they're capable of calculating the time between taps.

[potul]

I know it's an old thread, but I just wanted to post some curiosity.

I was doing some analysis of the Walrus arp87 delay pedal as it uses the FV-1 with tap tempo, and I was curios to see how it was implemented because there was a PIC inside. I realized looking at the pcb that it uses a pot input in the FV1 as a tap input, and the right output for the pulsing LED...

So.... I couldn't avoid take a look at the programs inside... and guess what? It uses basically slacker's tap tempo code.

It turns out the PIC is used for something else. Probably to manage the "infinite feedback"feature., as the feedback is controlled from outside the FV1

I was surprised to realize this piece of code was good enough for a commercial product. A point for slacker.

Mat

[Ice-9]

I was surprised to realize this piece of code was good enough for a commercial product. A point for slacker.

Mat

Why the surprise, Ian's Tap tempo code is great.

[ElectricDruid]

I was surprised to realize this piece of code was good enough for a commercial product. A point for slacker.

Mat

Why the surprise, Ian's Tap tempo code is great.

+1 agree. Plenty of stuff/ideas kicking around here turn up in "professional" pedals.

[potul]

Don't get me wrong... I didn't mean the code was not great.
But I always saw it as a creative way to get tap tempo out of the FV-1 without having to add much hardware, ideal for DIY. But in my head I thought that if I would design a commercial pedal, I would probably deal with the tap tempo outside of the FV-1.

Cheers

[Digital Larry]

Having the FV-1 do tap tempo is really accurate.  The only reason I can think you'd want to do it externally is that you either can't spare the code space or you can't afford to dedicate a pot or audio input to handle the sensing.

People are funny about code space.  Reverbs in general take a ton of code space, but things like delays, simple filters, and chorus hardly take any at all.  Lots of perfectly fine effects come in way under the 128 instruction limit.

[Ice-9]

Code space would be the consideration for using an external micro to control the tap tempo for the FV-1 but that does not come without its difficulties as it is easier for the FV-1 code to accurately control the tap. One benefit I could envisage would be for the micro to read both the tap footswitch and a delay time pot separately so that when one or the other is adjusted the micro can sent the relevant data to the FV-1 pot input thus only using the one pot input. But like I mentioned this won't be as easy as coding the tap within the FV-1.

[potul]

Code space would be the consideration for using an external micro to control the tap tempo for the FV-1 but that does not come without its difficulties as it is easier for the FV-1 code to accurately control the tap. One benefit I could envisage would be for the micro to read both the tap footswitch and a delay time pot separately so that when one or the other is adjusted the micro can sent the relevant data to the FV-1 pot input thus only using the one pot input. But like I mentioned this won't be as easy as coding the tap within the FV-1.

This is what I ended up doing in my own tap tempo implementation. For me it was a must to have a delay pot in addition to the tap tempo, and code space + available pots was also a design consideration.
After some testing I realized what you just said... using an external voltage to control tempo is not very accurate, and requires some kind of calibration. So what I did is handle all the LED blink, switch debouncing,  pot control and subdivisions externally, but still use a square pulse to set the tempo in the FV-1. This is really accurate.

[potul]

It seems much better to use microcontroller to send a voltage based on either a voltage pot's value or a tapped in value. It seems like the Keeley Delay Workstation does this.

Sorry to revive this old thread, but I couldn't resist posting this.... I had the chance to look inside a Keeley Delay workstation, and from what I could tell, it uses one of the ADC inputs for the tap tempo switch, and a pot for the delay. And, one of the DACs for the LED. So I assume the pot vs tamp_tempo selection is done also inside the FV1. same for the subdivisions in the delay that supports them.

[bartimaeus]

It seems much better to use microcontroller to send a voltage based on either a voltage pot's value or a tapped in value. It seems like the Keeley Delay Workstation does this.

Sorry to revive this old thread, but I couldn't resist posting this.... I had the chance to look inside a Keeley Delay workstation, and from what I could tell, it uses one of the ADC inputs for the tap tempo switch, and a pot for the delay. And, one of the DACs for the LED. So I assume the pot vs tamp_tempo selection is done also inside the FV1. same for the subdivisions in the delay that supports them.

That's really interesting, thanks for sharing! I hadn't considering using an ADC for a switch, but it would bypass the smoothing on the POT inputs so that's an added bonus!

I assume that means the "feedback" is just controlled by a pot input?

I think that Keeley is a bit unusual though. I think the Alexander Neo pedals use a micro for tap tempo, which seems necessary since those pedals have presets.

[potul]

I assume that means the "feedback" is just controlled by a pot input?

I think that Keeley is a bit unusual though. I think the Alexander Neo pedals use a micro for tap tempo, which seems necessary since those pedals have presets.

Yes, feedback is a regular pot.
Using tap tempo internally works fine but definitifely you have some compromises here. You cannot use subdivisions unless you manage it in the program (in this case a dedicated program), presets are not possible, and probably more. But this one really works smoothly. And the transition between tap tempo and pot is working really well. It's something I've always had issues using an external microcontroller.