Percussa Home / Shop / Contact /

Are my encoders broken?

SSP Bugs
#1

Bug description (state clearly and simply): encoders seem to jump around, go backwards and take an age to scroll though pages with high numerical values.

Steps to reproduce (use numbered list): see video link or use encoders to scroll through large value menus

Software version (blank if unknown): latest

Type (major or minor): major, or minor depending on which menus you frequently use, I’ve been using the SSP all day today and the encoders are driving me crazy in large menu’s. I’m starting to think I might have a faulty SSP or my encoders are knackered though rather than it being a bug. Would anyone be so kind as to view the video and tell me if this is normal?

Video link

1 Like
#2

does they work correctly when you go slower?

I’ve seen similar behaviour.
I believe its a software issue…Ive seen that recent updates have been trying to improve this, so looks like something thats still be worked on.

I’ve used encoders on some of my projects, and its not easy to get the feeling right.
encoders are digital, and are very high resolution, so you basically have to convert this into natural analog motion - this is complicated more, when you target generic parameters - some of which are non-float types.

the going backwards might seem really odd, but unfortunately its not - the encoders are high resolution, that they can pick up the slight anti rotation you do when you ‘re-grab’ the encoder - and because the menu is probably using a float to int (for index) conversion - at some time, this is enough to push it back to the previous entry.

is this an excuse?
no, of course not, rather we we should just perhaps be aware that some ‘obvious’ things are not that easy to ‘fix’, so might take a few iterations to get right.

1 Like
#3

Thanks for your reply and explanation that makes a bit more sense to me now and if you and others are experiencing the same thing then I’m relieved as was starting to thing my encoders were knackered!

Yes they work ok if I go slower although I’ve also noticed they also seem to have a sort of dead spot when trying to dial in really small numbers slowly, as in I move the encoder really slowly and there is a good bit of the turn that does nothing while turning before the values start to change.

The reason I was turning the encoder faster in the video is as I read in another thread here that brings this issue up that @bert mentioned the encoders have been fixed in a firmware update and work fine if you move them faster, which doesn’t seem to be the case for me.

I’ve been working with large audio samples within the sampler modules (which is one of the main reasons why I bought the SSP) and setting the start and end points can take quite some time to dial in due to the encoders being slow and along with selecting inputs and outputs in the patching menus with lots of patching options it can take multiple minutes to get to where I want to patch, for example in my video I’m 40seconds in just going from the second output options to the 4th output options!

Hopefully @bert can chime in on this with some input, maybe there’s a firmware update in the pipeline to address the encoders? I’ve only had my SSP a few weeks and I’m already loving it, but the encoders playing up was one of the first things I noticed and they are a real workflow killer for me at the moment. I have been hesitant to start this thread as It seemed odd that no one else has already experienced this problem.

I also don’t want to come across as being negative because so much else (everything) on the SSP is amazing, but the encoders and sample waveform jumping about in the window while editing/scrolling for start end points are both really frustrating to use.

#4

yeah, Im new too, so I noticed similar…
but I think recently Ive started to find (subconsciously?) the speeds that work…

however, I was very aware of it when building the VSTs, where i had ‘issues’ which I suspect are similar to the ones Bert faces.

let me give you an example:
in Rings we have Model, which goes from 0 to 5.
(in reality, I could have changed this to text to describe the model, this would then be the ‘same’ as your menu example!)

each time the encoder is turned, I’m told by ‘how much/fast’ it was turned.
the issue is I have to divide this down - because if I use ‘as is’, the encoder is SO fast, you won’t be able to select individual values - it’ll just zip from 0 to 5, and 5 to 0 :wink:

note: the encoder has to be this fast, since if the range is very large, we need this acceleration/resolution.

now, I could say, you have to turn it at speed X to register…
but then if you don’t turn it that fast, it will feel like it’s not registering - yuch, feels bad.

so instead, I combine the vales from successive turns, this generally feels absolutely fine, and pretty natural.
and I can also easily adjust how sensitive it feels to the user.

BUT it’s not perfect, in some edge case scenarios - when you are seeing 3 on the display, you might be at 3.0 or 3.9 (forget rounding logic, its irrelevant :wink: ) , this means the slightest touch on the encoder could take you to 2.9 (and so 2, and backwards) or 4.0

of course there are various ways to improve this, e.g. no movement after time x, acts as a reset.
and this is the kind of fine tuning i suspect Bert has been working on.

one interesting aspect of your video - is when you turn fast it doesn’t respond…
I can only think this is some kind of ‘prevention’ mechanism to stop the encoder flying so fast, that you end up at the the bottom of the list - which would be pretty annoying. if thats the case, Id say it’d probably be better to have a max acceleration, and use that rather than ‘stop’ - but this is pure speculation, as Ive no access to the SSP code.

anyway, as i said, this is not diminishing the importance of the ‘issue’,
I think encoder feel is probably one of the most important aspects of the UX on the SSP.

however, I just wanted to highlight, that whilst it may look like a very simple thing to ‘fix’, actually in practice, Ive found it can be quite tricky.

(the ‘fix’ might also be dependent on uses. i.e. it might need ‘fixing’ for particular module parameters - rather than just one ‘general purpose’ fix)

as a technical aside, its quite an interesting problem - I’d be interested to hear @bert thoughts on it.
e.g. I’ve been thinking about using a low pass filter on the encoder inputs, this could potentially smooth it out, if I get the frequency right - but it may be bert is already doing this.

1 Like
#5

Hey thanks again for the detailed reply.

You’re right, it soon becomes muscle memory when you use the encoders enough, when scrolling through menus I’m generally just steadily turning the encoder, quite often trying to place my finger on top and slowly turn in a circular motion as I find that the best way to get a constant speed for a few minutes with out the menu stopping or jittering out. I’m not going like a madman as illustrated in my video, that was just to show what I was experiencing at higher scrolling speeds.

It seem (to me) like the encoders need a few tweaks In most of the menus, but overall they work well enough to not be that much of a problem, apart from the bigger values where it quickly becomes quite frustrating. The offset values are another place I find myself in for a good few minutes of knob turning to dial values in.

I don’t know if something like a button combo or holding down an encoder could function as a jump to bigger divisions of a number or even in the patching menu to the start of the next set of inputs or outputs. So if you were looking to patch sample output 4 then rather than having to scroll through all the available options of output 1, 2 and 3 If you held down a button and turned the encoder while on output 1 it’d jump to each input or output…I’m just thinking out loud here really.

I agree with you, about the encoder feel being important, as they are used in almost every interaction with the SSP and menu. Hopefully Bert is working on an update :slightly_smiling_face:

#6

It’s not quantitative, but my SSP’s encoder seems to be able to control more smoothly than yours.
I’m not sure but it might be hardware issue.

2 Likes
#7

yeah, its funny, I’ve noticed Ive some how fallen into the habit of using one finger on top of the encoders to turn - not sure why :slight_smile:

button combos could be used, but users often don’t like because things become a ‘two handed’ operation.

similarly, they are ‘click encoders’ so you can do press and turn, but I’ve also found some users don’t like that, as its quite hard to press and turn accurately - but it can be pretty effective.

I personally like click on encoders to be used for ‘reset’ to default :slight_smile:

ha crosspost- and someone else using one finger…

interesting, that does appear to be smoother…
I will say, @FuzzedOut looked more ‘extreme’ than what I remembered of mine - but I’d noticed different speeds/techniques of turning had yielded different results.

now I need to go try again :slight_smile:

one interesting aspect of this to test, is if the number of items in the ‘menu’ affects operation … eg it might be encoder feels smoother when the menu has more or less items (not quite sure which)

btw: is it hardware issue or not?
one rule of thumb is useful here…
do all the encoders appear to act the same? does it happen it all parts of the software with ‘that’ encoder?

typically, if its a hardware/physical issue, it will likely affect one encoder not others , and it’ll be evident everywhere you use that encoder. e.g. one encoder might feel particularly jittery/jumpy, but not only in menus, but also when dialling in parameters with that encoder.

edit: quick test…
i cannot get mine to ‘not move’ , as shown in the OP.
BUT definitely one finger is much smoother (like @Handsonicsuki) than trying to spin by continually grabbing/twist the encoder
this I suspect is because you have a constant velocity on the encoder whilst using one finger, as its a continuous movement, rather than kind of ‘start/stop’ motion.

try with one finger @FuzzedOut, does this work better for you?

I also noticed there is a small bug… where sometimes the current item is jumping to the top, it doesn’t affect the behaviour, (the scrolling is correct) but it confuses the ‘eye’.
( i think its when you scroll past an item that is ‘selected’, but only seems to happen when scrolling fast)

1 Like
#8

I think mine work similar to that on small amounts of values in the selected menu. Have you tried that with a menu stacked with lots of patching options like a sequencer to sampler patch menu or when you are patching from one module to multiple other modules?

#9

Yes this is my main issue, the encoders seem ok with smaller numbers but with stacked menus with example lots of patching points it’s painfully slow.
I’ll try and see if I still have that exact patch saved or something similar that maybe I can share.

I get users often don’t like button combos but maybe it can be a menu option, personally I’d rather have to press a button and use an encoder that sit for 2+ mins scrolling to patch one thing!

I shall test the 1 finger rotate when I get home

1 Like
#10

Here it is.
I didn’t feel big different even if it is a menu stacked with several of patching options.

1 Like
#11

Hmmmmm…that’s interesting and a bit confusing, you seem to be giving the encoders some too! At least comparable to me.

In my original video I’m not actually spinning the encoders that fast throughout, it’s fairly steady at the point where the cursor stops moving I think.

I’m starting to go back to my original thinking that my encoders are fucked then. Just out of interest @thetechnobear how do yours compare with mine and @Handsonicsuki?

Edit: I wonder if maybe something else in my patch is making my encoders behave that way, possibly large sample files loaded into the (2) sampler slots. I’ll try and investigate further a bit later on.

#12

Here’s my case.

1 Like
#13

Thanks for posting this. That’s how I’d expect them to work.

I wonder why mine seem to be behaving like they do then?

So I guess my next question: Is anyone experiencing or experienced the same behaviour as what I’m getting in my video or if not has anyone been able to replicate my issue?

#14

It’s not exactly the same as this case, but I still think your case might be related to this case.

1 Like
#15

as I said, mine are basically the same as @Handsonicsuki.
though i can get the odd ‘stutter’ if I don’t use one finger, and keep velocity constant.
as in my original post, Ive seen the going backwards thing,
but Ive not had it ‘stop’ like your videos shows - and i cannot replicate that.

if its hardware, then that encoder should exhibit the same ‘stop’ behaviour on parameters.

1 Like
#16

You know I read that thread and watched that video when I first experienced this problem and dismissed it for some reason, but now I’m thinking that may well be what I’m experiencing.

Here’s another video Video 2

Seems like the 4th encoder is knackered :slightly_frowning_face:

#17

yeah, that’s doesn’t look good… you shouldn’t see it stop on continuous parameters :frowning:

you should probably message @bert, include links to both videos.

btw: id probably test the same thing on an empty patch, just after SSP has booted, perhaps using just the ENV module - just to eliminate ‘patch’ interference (e.g cpu/memory issues) - but you videos show quite low cpu load, so not too hopeful :frowning:

1 Like
#18

Yeah not looking good eh, no wonder I was getting frustrated, it seems like it’s gotten worse in the second video, gutted.

Thanks for everyone here that’s taken time to Chip in and post videos much appreciated.

#19

The fourth encoder really seems to have a problem.:worried: I hope your problem will be solved soon.

1 Like
#20

I’ve sent you an email to figure out what’s going on.

3 Likes