hey there

i'm using 2 pots to control some timings, standard wired like this:

gnd ----->>>>>>>>----- 5v
analog in___î

at the 5v side, i get a steady reading @0.99999
everywhere else, even at gnd side, i get small fluctuations (in the 0.000x range).
all the way CCW i get values up to 0.00015v.

in the 'real' world of analog synths an guitar pedals that wouldn't bother me at all.
but if i didn't smooth out those values, it seems the patch was eating a lot of Cpu and causing underruns from constantly updating the values.
i threw something together with a lot of multiplications and divisions and [change] and [int]'s to get rid of the bouncing decimals and smooth everything out as close as possible to the input 🙂 et voila, no more underruns.

but i was wondering, is there a standard way of doing this? i tried lowpass filtering the incoming signal, but to no avail (both in soft- and hardware), and what i cobbled together now seems both completely clumsy and rather arbitrary. how do you guys usually tackle this? or am i the only one seeing slightly drifting random-walkish values?

    Remork ow do you guys usually tackle this? or am i the only one seeing slightly drifting random-walkish values?

    it's fairly normal, especially when the 5V source is noisy. These ADCs do not contain an anti-aliasing filter, so high frequency noise is aliased back in the audio range ( see here for more details). A common solution is to apply a lowpass filter in software. In Pd. I'd have something like:

    [adc~ 3]
|
[lop~ 1000]
| <--- now it's ready to use

      Remork and divisions and [change] and [int]'s to get rid of the bouncing decimals

      More in general, I wouldn't use [change] on anything that comes from a sampled analog signal, as a tiny amount of noise will always be there even with close-to-ideal ADCs. You could create your own abstraction to detect a change with some hysteresis (e.g.: only output a new value if the difference between it and the last value you sent out is larger than a given threshold, e.g.: 0.001).

        hey giuliomoro
        thanks for that!

        well, the flux is extremely small, so it would appear steady enough, but it is constantly changing nonetheless.
        and i tried the lowpass, but no go.

        in fact, creating a subpatch to compare incoming numbers with the last one that got spit out, and adding a 'change' threshold for some hysteresis is exactly what i ended up doing.. perhaps my way of building it was a bit convoluted, but the idea is the same. so thanks for confirming that!

        and now that i review what i ended up with in the end, i didn't even use any [change] objects, apparently.. nice 🙂