Jumpy encoders

Elektron Gear Digitone/Digitone Keys
#1

I’m calling them encoders, but I’ve heard they’re actually endless potentiometers or something. Anyhow, you probably know what I’m talking about.

Sometimes when I’m using the encoders, the “cursor” position (I don’t know if that’s what it’s called) jumps around, making it very difficult to select what I’m trying to select.

I’ve noticed this happens often on the LFO page, and mostly with encoders D and H.

An example of what happens: if I’m changing the LFO depth, the cursor will all of a sudden start cycling through LFO destinations instead. This isn’t the only place where this happens, but it’s what happens most frequently.

If this isn’t a good explanation, maybe I’ll try to capture it on video.

I take care of my gear. No dust, no smoke, no dirty hands. In fact, I almost religiously wash my hands before a session – a habit I picked up from my guitar years, so I wouldn’t have to change strings too often.

Does anyone know how to troubleshoot this? Or is this better as a support request from Elektron? I don’t know if this is included, but I’m under the impression the Digitone has a 3 year warranty and I’ve had it for a little over 1 year.

Wonky Heat Encoder, anyone else experience this?
#2

Look at the encoder behaviour in test mode

Compare each encoder against the others and see if there are irregularities there

In my experience there are rather too many areas where the ‘gearing’ of these ‘encoders’ is way too fast and jittery for the underlying parameter list

User input is on a par with brain surgery. This is ultimately a software fix on the UX front and imho will likely be nothing to do with deteriorations to the hardware per se

As these Sin-Cos potentiometers are analog in nature there’s noise and heat and so on to include in the mix I guess, it’s not monitoring discrete steps

In places it is incredibly difficult to dial in an exact value without the ‘encoder’ skipping through the value you want … unfortunately test mode doesn’t offer simulations of sensitive number inputs, but it is possible to compare encoders

My gut feeling is that users would generally find the same parameters to be fiddly/jumpy/jittery rather than the same encoders on all parameters

The best advise would be to make a note of the difficult parameters to control, see if others are in the same boat and hope for a tweak to an algorithm

Dialling in 14 bit parameters to MSB (coarse) values is often waaaaay too tricky (i.e. 5.0), especially as the LSB(128 Values fine) is represented approximately in a decimal value

Doing this as parameter locks is a whole world of pain as you have no ‘snap’ modifier keys plus you’re also tying up a digit holding a trig

I’m trying not to paint too bleak a picture about this, it may well be a challenge, but similar ‘surgical’ user level input has been required on devices from the OT mk1 onwards in my experience. Some mitigation for this is needed imho, but I think it will take a dedicated bunch to isolate which parameters are too jittery for most people

This in turn may identify if there is a difference or deterioration in performance between ‘encoders’ if some have issues others don’t

My hunch is that this is only needing some software finessing that I hope will happen in time, but as some people clearly don’t mind this too much it may be better to identify all parameters which are objectively too jumpy to dial in efficiently and put this to Elektron to see if there’s scope for improvement. No doubt there are challenges to utilising these particular encoders for all desirable user input, but I hold out hope for a fix for this jittery input issue

5 Likes
#3

I’ve had this many times. LFO Dest page appears when adjusting Depth. It’s not duff encoders here (happened on old DT, still happens on same DT with replaced controller board) but testing should answer the question. Start up the DT while holding Func to enter Test Mode.

2 Likes
#4

The encoders seem normal in test mode, but I guess sometimes they seem normal even when controlling the parameters I mentioned. Every once in a while the menus jump, but not every time I use them, so moving the encoders around in test mode might not be exactly deterministic, if you know what I mean.

I’ll check out the encoders in test mode more times to see if I catch them misbehaving.

What exactly am I looking for in test mode? If the encoders are bad (hardware-wise) will I see the cursor jump or not move smoothly while in test mode? Is that pretty much the test?

Thanks for the replies. It sounds like this might be a thing. It’s somewhat manageable, just requires some patience – as long as it doesn’t deteriorate.

#5

Having this exact problem since May with my Digitone with the F one and confirmed by a test mode.

A light touch on the button makes the value jittering for a few seconds and when i want to set a value, displayed numbers keep oscillating in a jumpy dance for one or two seconds at the end of the motion.
This “dance” happens less to none when using fast motions with the button.

The “dance” shows only on numbers, it’s not affecting the display for the animation of the graphics like Detune and such.

Same…but it happened out of the blue after one and a half year of use.

It’s been it’s box since…Understanding the test mode verdict as an hardware problem and guessing it’s time for an intervention, but :

I would prefer this to the whole sending back (still in working warranty) , i really don’t know if it would apply to my case…but if the test mode confirmed it…

Anyway i’m pissed.

#6

There are two resistance tracks 90 degrees out of phase, those resistors are being read and there will be noise in a system like that depending on how fine you want to capture or how the reading is filtered etc, both are competing against one another

If an encoder is different in test mode it is perhaps a tiny bit more noisy, or dirty and given that these are akin to old style encoders they may be subject to similar ageing and so on and therefore may respond to having an appropriate maintenance intervention, strictly only if that was advised by support if indeed it is even doable. Keep in mind heat too.

I,be seen this a few times on one of my devices, where without input you may see a value shown briefly. This would only happen on a 14 bit number so the change in practice may equate to 1/16k of a fluctuation … or 0.0006 … so I don’t bother as it’s a bit the nature of the beast.

This is why I say it’s an algorithm thing and may or may not be a tricky thing to balance well to have both precision and feel and reliability etc

It’s best to ask support whether any behaviour falls outside of normal, my hunch is this is normal, but annoying… something that may benefit from a bit of TLC where parameters are jittery

The only other test I would advocate would be monitoring Midi on a jittery encoder that isn’t being touched, if it’s jittery then it may send a message …

My gut feeling is that the ‘gearing’ of user input needs a tweak to make it more usable on fine values or it needs more targeted filtering/smoothing when you are homing in on a precise value slowly

There are a few menus scattered through the devices where the scrolling through a half dozen parameters is so fiddly, there’s clearly scope to fix the general feel in a few places and that wil be doable on LFO destination entry imho too

Only Elektron can advise you if an encoder is not performing as it should, if the test mode had a high resolution numerical output it would be easier to compare them at home, the visual trace from an encoder on screen is only going to be so informative to the end user. But it was very effective for true encoders on mk1 devices as it would clearly show jittery feedback

I wouldn’t put energy into worrying about the hardware, but instead identify those parameters which appear uncontrollable and ask if that can be addressed

1 Like
#7

didn’t take long to catch it in action…

2 Likes
#8

Thanks for these informations.
I’ll put the DN out of it’s box to make a video of this problem so it’ll help with support.

1 Like
#9

Someone suggested, I think on another thread, giving the jumpy encoder several full turns in order to calm down the jumpiness. I just learned about this “fix” recently, haven’t done an exhaustive study of it, but it seems to be working.

1 Like
#10

I meant to suggest that too, it can help on guitar pots so scope to have similar temporary improvements.

@garf’s issue is a pain for sure, curious if that becomes less noticeable after that false trigger encoder gets a few twists and spins both ways

#11

Maybe that would help, but i’ve had it happen long into a session of twiddling.
It’s not really a hindrance, just makes the DT seem a bit flakey in use sometimes.

1 Like
#12

It’s pretty similar to my behavior, although yours seemed to chill out much faster. Sometimes when it bugs out I can’t set a parameter. When in this situation, I typically go to some other page and then come back to the LFO page later – I don’t know if that helps or if it just gives me something else to look at while time elapses and the encoder stops having its fit :wink:

#13

Twiddling knobs vs. multiple full turns are distinct, I think. Some encoders typically get only tiny movements from me. Those are the ones, I think, that need the multiple full turns.

#14

I found leaving the encoder in another position worked most of the time, I would make a temp save or copy, give the encoder a half turn and func+no/paste the pattern back .
I do think that some encoders are more prone to trigger than others, whether that is a physical difference with the encoder or something else I don’t know.

#15

Ok i’m lost.
Sorry, it’s going to be a liitle long but details are always needed when trying to identify behaviours etc.

But for those who might want to read a short version :
Everything seems back to normal …and i don’t understand why ( But with funny weird events before a “no errors” test mode) i will test it in real conditions to confirm (fingers crossed)

So, for the “long version” :

Got the DN out of the box, turn it on and the first thing i try is the one finger light touch/push on the faulty F…and no Jitters.
Proceed to make a few turns…no jitters.

At this point i wonder if i have false memories so i try E and a slight jitter occurs with a light touch. I make a few moves, and it gets stable and acts normally.

The same behaviour happens to two other rotary buttons :
A few jumps/make some turns/ back to act as expected after a few turns.

Then i make several touch on all Rotary Buttons and no Jitters.
Every buttons are ok…???

Turn off the DN, made the full turns series on ALL buttons (because why not ?)
make a test mode: No Errors.

Like i said…i’m lost.
Back When the jumps happened (only on F at the time) I did the full turns with the machine turned off but the problem persisted and the test mode showed errors on the F ( with a vertical line showing the actual jitters).

A few months of no activity later, the faulty Button/encoder is ok, the others that showed no problems acted funny for a second and then everybody is OK.

???

Conclusion :

I will test the DN properly this evening to check it’s behaviour on the long run and will report.
Trying to keep it cool and not celebrating yet, but if all is back to normal, i am SO clueless.

1 Like
#16

Yeah, the encoder issue I’m experiencing seems to be intermittent. I think that’s what you might be seeing too (?) It’s hard to catch it in test mode!

Is cleaning the encoders an option? I wouldn’t try without guidance from professionals (Elektron), but I’m curious if that’s a possibility. As I mentioned, my studio and gear is dust-free and clean, but it could be interesting to get them cleaned to rule that out. If that is an option, is that something that requires sending in for service?

#17

Yes, The intermittent factor may come into play but in my case, there are a few things that puzzles me :
The faulty one that got “fixed” ( it seems)…ok…but,
The other ones that never showed any issues and became problematic for a few seconds …and then back to normal…all that after a long periode without use.

I have a few “leads” that would be too much of a far stretch right now , but i’ll report after a good time of usage to see if they’re worth mentioning.

#18

I was just posting about a similar issue (linked) and I wonder if they’re related.

It’s a shame this is a common issue, but the advice to do a temp save, twist the pot back and forth, then reload has helped me a good bit.

Lagging encoders on DNK

#19

Might be related but my experience is not a lag. It’s fast, but the menus just jump all over the place. Mostly in the LFO page, when I adjust the LFO depth the menu for LFO destinations shows up and starts scrolling quickly through the options – when this happens it’s easy to accidentally change the LFO destination when I meant to change the depth. It’s all very fast actually

#20

Realizing that we all have different issues with these Buttons/Potentiometers/encoders but it doesn’t really change the thing : they love to be jumpy, either with menus, values, pages etc.

Regarding my issues, here’s one thread where i responded because i had the exact same behaviour the OP had with the Encoders/potentiometers on several (!!) Octatracks

Now reporting after a couple of hours of using my Digitone :
At the moment, i’ve only had tiny jump of value on the infamous F one but that’s all.
I don’t know if it needed “rest” or if the full rotation cycles did the trick for this one time.

Other things that i’m not even sure if they had an impact :
When i originally found this problem, i tried to go back to a prior version of the OS just to check but it did nothing, so i reinstalled 1.32A.

When i decided to prepare the machine for a potential return, i made a backup of sounds and projects and then a big cleaning of the user data.
So at this point i’m wondering if turning the machine on later in time, with nothing but factory data is relevant (i would say no, but what do i know ?)

For now i wont bring my data back and won’t use Overbridge, just to check if the stability is still there.

I really, really hope so because it’s the first time i’m using the DN since the end of May (!!!)
And…

I’m
Having
a
Fucking
Blast.