giuliomoro removed the cap, used the analog inputs 1 to 4 and vizualised the data through the IDE's oscilloscope, treating them in two sets groups. crosstalk still occured in both cases, but the above console error occured on one of them..

try getting ground from the analog input header and see if the crosstalk is reduced. Also, I understand that what you are seeing is that signals that are nominally grounded are being "lifted" away from 0. Can you try setting the pots to half way through and see if you see the same amount of crosstalk there?

    giuliomoro I've done that, it seems to reduce the crosstalk slightly - if one of the pots is halfway up and the others down, then the value of the highest one drops. but the error messages still occasionally occurs, and disconnects the bela... I've changed the sliders around, to see if it had anything to do with a defective one - it might be? whenever it shuts down, I need to remove the jump wire from the 3.3v in order to have the bela properly restarting again and showing up on the IDE. I run the program and then insert the pin to the 3.3v again.

    ground on analog input header / 3.3v

      gab_i whenever it shuts down, I need to remove the jump wire from the 3.3v in order to have the bela properly restarting again and showing up on the ID

      That's weird. It may be that you have something drawing a lot of current from 3.3V, maybe some dodgy connection on the breadboard? Can you measure the current that comes out of the 3.3V pin? It should, at any time, be 3.3/(10000*numSliders) Ampere.

      yikes..... rookie mistake. I had inverted the output and 3.3v jumper wires from the sliders to the bela i/o pins, slide potentiometer schematics seem to differ from one another :/ the bela isn't abruptly shutting down anymore. however, all neighboring channels pairs on the mux are crosstalking quite heavily (0.0 and 0.1, 1.0 and 1.1, and so forth). I've had to distribute them even more to bypass this issue - 0.0, 1.0, 2.0 , 3.0 etc. is there another way of avoiding drastic crosstalk between X.y channels for a given X - I have 10 more potentiometers to add.

      sorry for the troubles!

        gab_i however, all neighboring channels pairs on the mux are crosstalking quite heavily (0.0 and 0.1, 1.0 and 1.1, and so forth

        That's not expected. Is there any more wiring error there to spot?

        @giuliomoro I am experiencing a similar issue with crosstalk on the multiplexer. If I have two piezo trigger inputs anywhere within the same column (0.0, 0.1 ... 0.7), then the trigger of one piezo will register as a trigger of the other.
        I have also tried spacing out the piezo inputs within the same column (ie. 0.0 and 0.7), however this hasn't helped.
        My wiring is set up:


        hmm no nothing apparent... I'm getting the following: if any X.1 channel is high then X.0 is lifted (even though it is at its lowest). and don't get any readings from the X.0 channels alone, when all X.1 are at lowest.
        I'm running the pd multiplexer example patch, with 16 channels set on the IDE

        I see why it could be an issue with piezos: they have high output impedance and so may not provide enough current to quickly update the voltage at the ADC's input upon switching the multiplexer. But it still it seems weird.
        Just to make sure, I'd suggest you plug the analog outs directly into the multiplexer's 0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7 inputs, set them all to a fixed voltage, except for one. That one, make it variable and see if the others are affected by it.
        Something like:

        [sig~ 0]
        |
        [dac~ 3] >> connect to input 0.0
        
        [sig~ 0.05]
        |
        [dac~ 4] >> connect to input 0.1
        
        [sig~ 0.1]
        |
        [dac~ 5] >> connect to input 0.2
        
        [sig~ 0.15]
        |
        [dac~ 6] >> connect to input 0.3
        
        [sig~ 0.2]
        |
        [dac~ 7] >> connect to input 0.4
        
        [sig~ 0.25]
        |
        [dac~ 8] >> connect to input 0.5
        
        [sig~ 0.3]
        |
        [dac~ 9] >> connect to input 0.6

        Then the last one. Initially make it static:

        [sig~ 0.35]
        |
        [dac~ 10] >> connect to input 0.7

        Verify that all the readings from 0.x are static (note: expect some low-amplitude noise and be aware that the input readings will not be exactly what you send to the output, but they'll be approx 4.096/5 * value.

        Then make the last one dynamic:

        [phasor~ 0.5]
        |
        [dac~ 10] >> connect to input 0.7.

        Does it affect the other readings?

        fixed voltages

        with last one dynamic

        analog out 0 - 7 to mux 0.0 - 0.7

        Can you show what you are sending to the dacs ?

          A couple of things to keep in mind:

          • to avoid ambiguity, below I report in angled brackets the channels corresponding to the displayed channels (using analogChannel.muxChannel notation):
            mux channel [x. 0 ]: <0.0, 1.0, 2.0 3.0, 4.0, 5.0, 6.0, 7.0>
            mux channel [x. 1 ]: <0.1, 1.1, 2.1 3.1, 4.1, 5.1, 6.1, 7.1>
          • unconnected inputs are a distraction: they are floating and so their value is irrelevant and should be ignored. Given the previous point and the fact that you only have 0.y channels connected, only the first column of each row is to be taken into account: they are <0.0> in the first row and <0.1> in the second row and they should be affected only by [dac~ 3] and [dac~ 4] respectively
          • however, I don't see the <0.0> and <0.1> being affected by the corresponding dac channels the way I expect it to: expected readings should be 0 and 0.061, so I'd recommend double checking the wiring. If you have pin-to-socket wires, I recommend bypassing the ribbon cable and jumpering directly to the multiplexer inputs. You can also try starting from [sig~ 0.2] for [dac~ 3] and then increase by 0.05 for each.
          • also try running with 8 multiplexer channels, that will print 8 values and you should look at the first column only (as all the others are disconnected); the values on the first column will be <0.0> on the first row, <0.1> on the second row... <0.7> on the last row

          I don't have a multiplexer with me right now but I should get one on Thursday or Friday