Untriggered resets on Stairs

[glibglobber]

With a clock signal on Digital 1, Stairs is giving me weird resets where it stutters around step 1 and 2. As in, it can't complete its full cycle because it goes from step 1-2 back and forth.

[5-lagu]

Getting the same behaviour with Shredder. Clock in on Dig1, shredder usually only runs through top two to five-six steps before resetting.

[djphazer]

I would double-check your calibration... jitter on the CV inputs could be resetting the position on these applets. At one point I discovered Carpeggio, Shredder and others wouldn't work at all because CV1 was reading ~0.01V unpatched.

[5-lagu]

I would double-check your calibration... jitter on the CV inputs could be resetting the position on these applets. At one point I discovered Carpeggio, Shredder and others wouldn't work at all because CV1 was reading ~0.01V unpatched.

I know my uO_C flutters between -0,03 and -0,04 on the jacks. I'll try to zero it out, but I'm lacking a good multimeter to get the calibration any better. But what is the threshold for reset on these apps? 0V? The Wiki doesn't say. Wouldn't it make sense to make it a positive gate or trig value, like +2,5V or something?

[benirose]

I'll take a look in the guts of the firmware to see what constitutes a "clock" or "gate" on either digital input, I'm surprised it's something that small tbh and extra surprised that a negative value would cause it to be set on a digital input! If anyone else identifies anything in the code worth digging deeper into, let me know!

[5-lagu]

Yeah, I've been looking at the code, but even though I have some knowledge of C(++/#) I couldn't see anything obvious. I can also not rule out that, even though I bought my uO_C "professionally built", it can be something wrong with my module (or its calibration). I also have a problem makes the DualQuant go out of tune when it receives a clock on the digital inputs, but works fine without. This is the same on the original Hemisphere Suite and the Benisphere FW...

[5-lagu]

I've found, after experimenting a little, that applying a very small positive voltage to the CV inputs C and D (the ones that moves the cursor vertically) fixes the problems for me. As noted, my CV inputs flutters around -0,03-4 volts which is probably causing Shredder to move the cursor back to the first line.

[djphazer]

This is definitely an individual calibration issue. You don't really need a multimeter to go thru and reset the 0V calibration point for the inputs. Just go to the "Setup / About" app and press the left encoder to get there...

For the record, the input threshold for DetentedIn() is +/- 64, which is a quartertone, or about ~0.0416V. If we really wanted to, we could increase this threshold to accommodate calibration errors like this...

[5-lagu]

I've had my uO_C professionally calibrated since reporting on this, and I can confirm that it fixed the issue. The original poster hasn't chimed in on this, so unless you think the input threshold should be adjusted, this issue can probably be closed.