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 
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
) , 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.