It seems to work with this:
#N canvas 50 47 212 440 12;
#X obj 25 163 snapshot~;
#N canvas 1 67 450 300 LowPass 0;
#X obj 49 102 lop~ 10;
#X obj 49 138 lop~ 10;
#X obj 49 162 lop~ 10;
#X obj 50 72 inlet~;
#X obj 49 187 outlet~;
#X connect 0 0 1 0;
#X connect 1 0 2 0;
#X connect 2 0 4 0;
#X connect 3 0 0 0;
#X restore 25 79 pd LowPass;
#X obj 25 198 int;
#X obj 25 260 / 1000;
#X obj 25 289 change;
#X obj 25 317 abs;
#X obj 25 351 pow 2;
#X obj 25 392 outlet;
#X obj 25 48 *~ 1200;
#X obj 25 226 clip 0 1000;
#X obj 113 92 tgl 15 0 empty empty empty 17 7 0 10 #fcfcfc #000000
#000000 0 1;
#X obj 113 68 loadbang;
#X obj 113 112 metro 20;
#X obj 25 18 adc~;
#X connect 0 0 2 0;
#X connect 1 0 0 0;
#X connect 2 0 9 0;
#X connect 3 0 4 0;
#X connect 4 0 5 0;
#X connect 5 0 6 0;
#X connect 6 0 7 0;
#X connect 8 0 1 0;
#X connect 9 0 3 0;
#X connect 10 0 12 0;
#X connect 11 0 10 0;
#X connect 12 0 0 0;
#X connect 13 0 8 0;

or, in a graphical mode:
[adc~ x]
|
[*~ 1200]
|
[pd LowPass (3x[lop~ 10])]
|
[snapshot~]—[metro 20]
|
[int]
|
[clip 0 1000]
|
[/ 1000]
|
[change]
|
[abs]
|
[pow 2]
|
[outlet]

If somebody have a correction or a better proposition...

i have a tendency to do the conditioning/calculations after smoothing the voltages - take 'raw' data, remove the jitter, and then see what there is to work with - but i guess the end result would be exactly the same 🙂

as long as you reach 1000 or slightly more before the [clip]object, you should be fine.
if the pot reading doesn't fully reach 0 on the other end, you can throw a minus offset in there as well.

    downloaded your patch, but still need to install the ELSE lib so can't try it out just now.

    looks like i'm missing three objects.
    i should think one can come up with a vanilla workaround for the [rescale] and [s2f~]objects, but i might be a tad optimistic here. 🙂
    any specific reason to use [brown](which i'm assuming is brown noise) over [random]?

      Remork
      Yes, the minus offset a good idea !
      And I'll set the conditioning/calculations after smoothing the voltages, as you said.
      It's still a little bit blurry for me how the Bela convert Voltage to 0-1 range because the real voltage values are not equals and not reaching 5 V, and perhaps not 0 V. So what do we get in Pd in these cases ? Do we have to consider that we could have for exemple 0.15-0.85 ranges in Pd instead of a 0-1 ?

          Remork
          About the (only !?) three objects:
          - [s2f~] is only used to visualise the envelope rise & fall ampltitude when you're working on the patch on your computer (see in [pd ENV (X)]), so you can run the ATTAC506 without it.
          - [rescale] I can't remember why I have use this objet, perhaps it could be replaced by [clip] (in [pd ENV (X)] replace [rescale 10 10000] by [clip 10 10000]. I'll try it today >>> EDIT: IT DOESN'T WORK OBVIOUSLY !
          - [brown] instead of [random] because if I paste some of the Alexandre Torres Porres Pd Help, we could understand that if we want to go stochastic, we need a ""Weighted random", where some random values have more probabilities of happening than others." And especially [brown] which is for ""brownian motion", which is a type of random walk. The difference to "drunkard" (an other object) is that we have the same probability to go up or down and when we reach the bounds the values are folded back." But I don't say you can't do it in an other way and I'm not saying I'm not wrong !

            FatJak Do we have to consider that we could have for exemple 0.15-0.85 ranges in Pd instead of a 0-1 ?

            in my experience, yes.
            Pd just expects 'ideal' voltages from 0-5v, however, reality isn't like that 🙂
            which is why some smoothing and some remapping comes in handy.
            sometimes there's even a slight difference between different inputs, so i tend to treat them individually. because i'm overly fussy about details 🙂

            [rescale]sounds like it would be a different fuction than clip - more mapping than limiting?
            sounds like something closer to the conditioner patch, actually 🙂

                Remork

                Remork because i'm overly fussy about details

                I understand ! I spend to much time with that ! 🙂

                Remork so i tend to treat them individually

                I was exactly thinking to do the same.

                About [rescale]: because the patch use the [brown] object, which send by default 0-127 values.
                `Help' file say: "By default, [rescale] rescales MIDI input values from 0 to 127 (including floats) into another range of values (0-1 by default). You can also set an exponential factor (1 by default - linear). All these parameters can be changed by arguments."
                So I don't know how to replace it easily by another object/calculation, but sure it can be done.

                      just divide or multiply to your target value?
                      i would think, divide (0 - 127) by 127 to get (0 - 1)..
                      or multiply by 7.88 to get (0 - 1000), approx..

                      and it's easy enough to add an offset: multiply (0-127) by 7.8 to get (0 - 990), then add 10 to get (10 - 1000).
                      i don't think it's more complex than that?

                        Remork
                        Sorry, perhaps i'm not focus enough, but yes, it's easy to convert a 0-127 range to another stable one, but in the ATTAC506, the destination range is a variable one, with variable and independant min and max values, and the [rescale] object make a good job for this.

                          oh yeah absolutely
                          i'm probably just trying to get everything into Pd Vanilla hahah
                          force of habit, sorry!

                            Remork
                            Good point.
                            I'll try to take the time to replace the [rescale] object by a working [expr min_value + ((max_value - min_value)/127) * incomming_random_value]. But there is still an Else object with [brown]...

                              i know, those libraries are there for a reason.. sometimes you just can't avoid them.
                              and sometimes there's no point in reinventing the wheel..

                              it's not like i never use externals or libraries, vanilla just makes everything that little more portable or shareable.

                                Remork
                                I understand, and I'm agree.
                                As a beginner, it's not easy to make a straight and definitive choose between the difficult way of deep learning that keep simple tools adequate and easily shareable and the way, as a musician, that let you enough time to experiment with your tool.

                                By the way, i'm working (losting time) on an abstraction [Pot-Init](pot-initialisation mode) that allows to adapt the real voltage range of each potentiometer to the 0-1 range of pure data, and store it (where i'm quite stuck), with Pepper in the rack, not connected to the IDE.
                                Perhaps it's unuseful... (I'm I reinventing the wheel ? 🙂)

                                    as far as reinventing the wheel goes:
                                    https://patchstorage.com/vanillabrown/
                                    here's what i hope is a working version of a vanilla brownian generator.

                                    it's very much based on the ELSE version.
                                    tested them side by side and found no difference whatsoever. YMMV.

                                    i'll try to use it in your patch soon, but i'd have to do some revisions for pepper v1 before i can truly test it.

                                      FatJak By the way, i'm working (losting time) on an abstraction [Pot-Init](pot-initialisation mode) that allows to adapt the real voltage range of each potentiometer to the 0-1 range of pure data, and store it (where i'm quite stuck), with Pepper in the rack, not connected to the IDE.

                                      do you mean a function where it reads the 'real' values, adjusts them and saves them - without connecting to a computer?
                                      while such a mapping is certainly necessary, i'm not sure if the values drift over time.. so i would think that once you have the values for all 8 pots in your Pepper, you can use these for every patch afterwards?

                                          Remork do you mean a function where it reads the 'real' values, adjusts them and saves them - without connecting to a computer?
                                          while such a mapping is certainly necessary, i'm not sure if the values drift over time.. so i would think that once you have the values for all 8 pots in your Pepper, you can use these for every patch afterwards?

                                          Yes, I have thought of the possible variation of voltages in time. [Pot-Init] need to be incorporate in the [ReadAnalog] as an abstraction. You could use the Pot-Initialisation mode only one time and keep use these values for the rest of your life or use the Pot-Initialisation mode every time you power the Pepper.
                                          It works on my computer, but I need to find a solution only with Pepper to store the values to be readable after reboot. On computer, it's easy with the [savestate] object, by saving the parent patch.

                                          Basic operating manual: power on the PEPPER with button 1 engaged, release it after you see the first blink of led bargraph, then fully turn each pot from a side to the other and let them here, in their max or min positions, press button 2 to quit pot-initialisation mode.

                                              FatJak
                                              i'm sure it must be possible to save and recall a text file somewhere on Bela.

                                                  by the way, the [else/rescale] object actually allows for inputs greater than its designated values - which actually happens in [else/brown], where you sometimes will get values over 1 after adding the step to [fold]’s output.

                                                  my patch does this as well since it didn’t seem to matter, but it could easily be remedied with a [clip] object.