Tap Tempo Delay out of sync

[Ice-9]

the 11.28MHz crystals are designed for 44.1ksps playback.  if the original design was for 48ksps, and then they changed it down the line and didnt fix all the code, it could cause a frequency shift (if the codec is in master mode).  this would give a 10% frequency shift, although it would slow the BPM down, rather than speed it up.

The OP said that they get 133-135BPM when they tap 120bpm. That is very suspicious to me because 135/120 is exactly 1.125. 48/44.1 is only 1.088, so it doesn't provide a big enough effect to explain what we're seeing here.

just double checked the atmel datasheet.  the internal RC oscillator is factory calibrated to +/-10%.  so that definitely sounds like the issue.  it can be recalibrated to +/-1%, which should probably be close enough.  im suprised they didnt do that at the factory.  but if you can get pictures, it might be that they used a cheap ceramic resonator, in which case replacing that would do the job as well.

Highly unlikely in my view. I haven't used the Atmels but the PICs have a similar RC oscillator with a similar spec. In general they're extremely close to the stated value, and the +/-10% is just so they don't throw many anyway at QA. Furthermore the error reported is *more* than 10%, and seems to affect *all* units, if what's reported here is correct. That wouldn't happen if it was statistical variation between units within spec.

HTH,
Tom

In that case it is just poor code. It is hard to believe that it hasn't been fixed in newer units though as they must be getting some poor feedback from customers.

[ElectricDruid]

In that case it is just poor code. It is hard to believe that it hasn't been fixed in newer units though as they must be getting some poor feedback from customers.

Worrying too much about "Time to market" ruins another potentially good product? When will the marketing department learn that a sh*te product hurts you far more than a late, brilliant product ever does?

2 cents,
T.

[drolo]

I totally agree. It's a shame as they have quite nice products, a bit different than the other stuff coming from China lately, which are just copies of other pedals.
Unfortunately inconsistencies like these, the fact that the products can only be purchased through some "shady" sellers on ebay and such plus the fact that they won't reply to any email makes it kind of a deal breaker. Too bad for them ...

[g_u_e_s_t]

did anyone ever read the fuse bits and lock bits off the atmega?  im just curious whether a fix is possible.

[drolo]

did anyone ever read the fuse bits and lock bits off the atmega?  im just curious whether a fix is possible.

Nope, and don't know anyone who knows how to do that, I guess i will have to live with it ... or sell it  :-(

[BlueRed]

Hi,

i am new here.
But i have also the delay problem.

But i have found some other bugs.
Can anybody please verify that?

Select the Stereo Delay, connect both output channels (stereo)
Turn the Delay Tail on, and the Bypass mode to FET.

Now feed a signal into the NUX Timeforce and tap a tempo with the tap tempo button.
Now the delay sound gets distorted on one outpuchannel.
If you now turn the time know the distortion (artefacts) are gone and the delay works normal ....
Taping again and you have instant a distorted delay sound.

Next bug is:
Revers delay.
Turn the effect on and turn on the delay tail.
then disable the delay effect by pressing on/off and you will hear a phased out sound.
If you turn of the delay tail it will sound normal.....

It would be very nice if someone could try this on your own time force.

b.t.w. i have an atmel ISP programmer and a bit knowledge in asm  programming
i want to be shure that the bugs mentioned above are not an error of my very own device bevor i start soldering an isp connector

[drolo]

I have not noticed these issues as I have never tried to use it in stereo. I will give it a try if I find some time this weekend.

But speaking of other issues, do you also notice a lot of noise on the looped tracks? Like white noise that gets amplified every time you overdub the track ?

[g_u_e_s_t]

b.t.w. i have an atmel ISP programmer and a bit knowledge in asm  programming
i want to be shure that the bugs mentioned above are not an error of my very own device bevor i start soldering an isp connector

sorry to hear its not working well, but it is cool to hear you know asm.  if the lock bits arent set, you can just read out the code and work with it.  unfortunately, the problems you describe sound like they are on the DSP, although maybe there are some workarounds.

[BlueRed]

@drolo:

Please try it out i would be very happy to know if that is an issue of my model or a general problem of the dsp programming.
About the white noise, i also did notice it, but only if you drive the input to high.
On a lower input level itīs okay and i dont have any white noise.

About the stereo delay.
I would be realy happy to have a feedback about this.
If you check the stereo delay please connect it in stereo and use a headphone, because its easylie to hear on the right outputchannel.
The artefacts are only ocoure on the right outupt channel, the left channel is okay and they only are hearable if you use the TAP switch.
The aretefacts will vanish if you turn the time knob a little bit.

I think nux has messed up the controlling frontend (the atmel avr) for the DSP.

[drolo]

@drolo:

Please try it out i would be very happy to know if that is an issue of my model or a general problem of the dsp programming.
About the white noise, i also did notice it, but only if you drive the input to high.
On a lower input level itīs okay and i dont have any white noise.

About the stereo delay.
I would be realy happy to have a feedback about this.
If you check the stereo delay please connect it in stereo and use a headphone, because its easylie to hear on the right outputchannel.
The artefacts are only ocoure on the right outupt channel, the left channel is okay and they only are hearable if you use the TAP switch.
The aretefacts will vanish if you turn the time knob a little bit.

I think nux has messed up the controlling frontend (the atmel avr) for the DSP.

I finally got to try this in stereo but I could not reproduce your issue.

Seems like not only they messed up the code but have very inconsistent quality control ... :-(

[trisbone0]

hi,
I write you from France, I just bought a nux time force; I ve put a bad power supply so it burned!
I m trying to fix it, but i need to have schematics...
or if someone can tell me what component is Q1, because it seems to have burned.
I ve just tried a few momnt with the battery and found the se problem on the tap tempo.
too bad!
thank you
Tristan

[drolo]

Salut Tristan,
Sorry no idea  it's all too small for my poor eyes to identify anything.
how did you fry it? Perhaps follow the power line until you identify something thay could be damaged

good luck

[trisbone0]

thank you for your answer,
I just found the Q1 seems burned but I don t know what it is...
don t know what to do

[drolo]

could be a voltage regulator. can you read something on it? there is a pic showing Q1 a few answers back but its hard to read what it says, its too small

[deepMago!]

Hi,
I know it's an old post but yesterday I've bought one of that. Just opened because I would like to lower the volume output of the looper (no volume control, shame).
Take a look at the board that is very similar to the one photographed I saw different revision, mine is VER:8.0   2013-10-16. In the photo version seems to be 5.0. The other one is no yellow wire on the downside... I think this is the variation.
I've not checked with a metronome if Tempo it's right on mine, but it seems.
Under the display the Atmega still no have external resonator or quartz (the MCU version is 2.1) so I think for Tempo issue it's a software upgrade.
If I mod something I'll post on this thread.

Bye.

[chuckd666]

So yours taps with reasonable accuracy?

[deepMago!]

I've just checked now with the iphone metronome app and it's perfect also the BPM showed.

[pinkjimiphoton]

not to bump a zombie, but 10- 20 ms off isn't enough to even hear, so why worry about it?
mine works fine, never had any issue with it a reset didn't fix.

i mean... you can't tell the diff, and honestly, to be that critical isn't gonna get out of sync enough to matter when playing with other human beings. most people's time will wander faster and slower where that amount of time is so negligible it's totally overkill to worry about for most if not all uses.

sorry to be a buzzkill, but we're talking some pretty picayune differences in time that i would bet you couldn't tell if put to a blind test. and since you can dial in the EXACT time you want anyways, seems to me there's no harm/no foul involved.

i mean... tapping 4 times in a row it is gonna average out the taps to the closest tempo YOU input. it's not crazy to think between taps you could me that many milliseconds off. seriously.

if it works, don't sweat it. it's not a long enough "glitch" to matter. if it does at all. jmo, obviously your mileage may vary. most of the guitarists i've worked with, myself included, tend to think delays sound better slightly off time anyways.

there's nothing "human" about digital perfection. peace.

[chuckd666]

Now to sort out my taptation being completely out of time. 

[cloudscapes]

not to bump a zombie, but 10- 20 ms off isn't enough to even hear, so why worry about it?

Because if you're tapping out the delay as close as possible to a drum crack, or another loop, yo uwant to minimize drift. The less accurate the tap-tempo is, the more it'll drift with each loop of the delay. Yes you *will* hear a difference, at least in cases when you're syncing it with something else.