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