unfortunately, this is down to the accuracy of the pots (or possibly controller firmware we can’t update)
in the last OS release, I fixed a bug so that pots correctly report 0…1 (0…1023) , and also wouldn’t fluctuate… so generally it looks really stable.
but the issue is whilst the pots look like they have 10 bit accuracy, its not really… its jumps arounds,
the best way to see this is to do [r knob1Raw]->[print], you’ll see it jumps from 0 to 13, and from around 1018 to 1023.
and the centre point is similar, it should report 511 (1023/2 rounded) , but instead you get 510, and 514, so you are a small amount out.
to be honest this is perfectly normal when dealing with pots, and is normally handled in software.
… we could do this in the OrganelleOS (in a similar way I did with smoothing) , but often it doesn’t really make sense unless you know what your using for (and would also tend to reduce resolution further)
e.g. here the centre value is important, but for others 3 o’clock and 9 o’clock might also be important, for other uses it doesn’t matter at all, as long as its a linear progression.
So the best/most flexible thing is to ‘leave it to the patch’, but that means more logic in the patch, where you can do things based on what the value is being used for … but thats kind of a pain/hassle.
e.g. for this example, it would make sense to have a ‘detent’ around certain values e.g. 0, -1024,1024.
the easiest approach for most patches is not to use large values, as obviously the multiplication, also multiplies the error, i.e. using a coarse tune in semis, with a fine tune in cents will provide a better user experience.
anyway, this is precisely the reason in Orac, I have parameters types, so that my Kontrol external can deal with the messing about of types, making them nice for users, but the patch/module code can just concentrate on the dsp… on the musical stuff.
(this is why I created Kontrol, because I found doing all this parameter handling/display pretty laborious in PD)