Ok, back to Pure Data and knowing how that works :-)
Two questions::

---> I'm trying to find out what pure Data gets from the MPR121 via render.cpp
I managed to print this

 rt_printf("%d ", sensorValue[i]); 

:-D
--> so the MPR121 gives values from 0 (state of not touched) to 110 approximately
I need an object in pd that does not send bangs (like [route] does) but a construction that works with a threshold (when the value is higher than 30, button is pressed, play sound)
Any ideas? - I think I know about an object, but I don't know how it deals with the array of 12 numbers..

---> Render.cpp does not want to print rt_printf("%d ", sensorIndex); (commented out in the following code snippet)
Is this because sensorIndex is just a very local variable?
is it ignored?
Is it a problem (seems not to be the case..)

// Auxiliary task to read the I2C board
void readMPR121(void*)
{
	for(int i = 0; i < NUM_TOUCH_PINS; i++) {
		sensorValue[i] = -(mpr121.filteredData(i) - mpr121.baselineData(i));
		sensorValue[i] -= threshold;
		if(sensorValue[i] < 0)
			sensorValue[i] = 0;
		libpd_float("sensorIndex", (float)i);
		//rt_printf("%d ", sensorIndex[i]); //error: use of undeclared identifier 'sensorIndex'
		libpd_float("sensorValue", (float)sensorValue[i]);
#ifdef DEBUG_MPR121
		rt_printf("%d ", sensorValue[i]); //prints the values of the sensor when DEBUG_MPR121 is define at beginning of programme
#endif
	}
#ifdef DEBUG_MPR121
	rt_printf("\n");
#endif
	
// You can use this to read binary on/off touch state more easily
//rt_printf("Touched: %x\n", mpr121.touched());
}

Full render.cpp file is here:
https://framabin.org/p/?6facff6f6e1a593b#XZ1pyi4ED24QQQ+dUT9aEfZh+IzhXY58XUYzLIHQw8E=

And, thanks - you made my day!
greetz,
dywen

    dywen ---> Render.cpp does not want to print rt_printf("%d ", sensorIndex); (commented out in the following code snippet)

    there is no variable called sensorIndex. In fact the value you are sending to the "sensorIndex" receiver in Pd is simply i.

    dywen I need an object in pd that does not send bangs (like [route] does) but a construction that works with a threshold (when the value is higher than 30, button is pressed, play sound)

    could be

    [r sensorValue]
    |
    [> 30]
    |
    [select 1]
    |
    [somethingThatPlaysSound]

    ?

    Hi,

    Ok, I made a testpatch to simulate the sensor (as i don't know another way (yet) to get the data from the sensor into pd via Bela).

    When the slider is at 0, the MPR121 sensor is not touched
    I have put the threshhold at 30, because sometimes proximity and not touch is detected - to be changed at will.
    alt text
    https://framabin.org/p/?d2e0eebe6a1f043c#MmaUCw4CZUU2L08AwD32Dg3Dk9TRG5KXQgW0jfMwYmU=

    This is my translation to Pd&Bela
    And it works! For the moment for pin0 on the MPR121

    alt text

    Pd code:
    https://framabin.org/p/?95c0a2a50f7b1d1e#Q/+/6HwTwCfmfEvZSmI2ypZMmmiIJsCBGK0I36f9FqE=

    Lovely..
    Now figure out how to get the 8 values from the MPR121 chip
    (by doing [r sensorValue 0 1 2 3 4 5 6 7] ? - after lunch..)

    Greetz,
    Dywen

      dywen Now figure out how to get the 8 values from the MPR121 chip
      (by doing [r sensorValue 0 1 2 3 4 5 6 7] ? - after lunch..)

      send a list!
      e.g.:

      	        libpd_start_message(8);
                      for(int n = 0; n < 8; ++n)
                          libpd_add_float(sensorValue[n]);
      		libpd_finish_list("sensorValue");

        Of course!
        But Pure data still sees them as one

        alt text

        They bang together
        When I touch the 0 of MPR121 both values get printed - when I touch the 1 of MPR121 it's the same.
        I should be able to pour sensorValue into an array (but a pd array is not the same as an array in C..)

        The extra argument (0 or 1) to [r sensorValue] is ignored I believe.

        Print straight out of the receiver:

        [r sensorValue]
        |
        [print]

        and you will see that they come in as a list. However, when you go into [> ], only the first element is considered.

        So try this

        [r sensorValue]
        |
        [unpack f f f f f f f f ]
        |  |  |  |  |  |  |  | 
        each of these is one of your values.

        Hi and hmm
        it seems that unpack does not suffice - but the filtering works out well (only bangs when touched)

        alt text
        - When I touch pin 0 of the MPR121 it prints out 0: bang
        - When I touch pin 1 of the MPR121 it prints out 0: bang
        - When I touch pin 5 of the MPR121 it prints out 0: bang

        In the Arduino description I found they pack before unpacking - but that's another pd library which is not in Vanilla.

        So close - and yet so far

        [r sensorValue]
        |
        [print]
        ---> Did not give a list
        alt text

          dywen

          > [r sensorValue]
          > |
          > [print]

          ---> Did not give a list

          what is your C++ code at this point?
          Are you sending this?

          	        libpd_start_message(8);
                          for(int n = 0; n < 8; ++n)
                              libpd_add_float(sensorValue[n]);
          		libpd_finish_list("sensorValue");

          IMPORTANT: are you sending something else?

            giuliomoro
            hey,

            yes, it's in:

            // start DSP:
            	// [; pd dsp 1(
            	libpd_start_message(8); //get data from all 8 MPR121 pins
            	libpd_add_float(1.0f);
            	for(int n = 0; n < 8; ++n)
                	libpd_add_float(sensorValue[n]);
            	libpd_finish_list("sensorValue");
            	libpd_finish_message("pd", "dsp");
            

            --> if I'm sending anything else, good question.
            The render.cpp from luiszayas has a lot of extra stuff - midi etc - but I don't know what can be kept and what is too much.
            It's pasted here:
            https://framabin.org/p/?5d16d77f039d8958#QYF2tXlzMwCrGdw0525a0wGyhfVgd5f2zpvurT7Hr3E=

            In what function is it? By the looks of it, it is in setup(). It should be in render() instead.

            yep, it was in setup, not render.
            (I had a - bad - reason for that)

            Looking better!

            Now it needs serious debouncing - I think
            Touching once, briefly, gives 100 bangs (or more - who knows)

            ----> Too many messages have been printed to the console too quickly. Reduce your printing frequency

            so now you are sending one message every block(16 samples). You could add a [change] to your patch after the [unpack] to only let a message through when it is different from the previous one.

              Now the debouncer blocks too much
              alt text

              I used your debouncer for floats (and these are not floats, of course)
              alt text

              hmm..

              giuliomoro so now you are sending one message every block(16 samples). You could add a [change] to your patch after the [unpack] to only let a message through when it is different from the previous one.

              I don't think you need debouncing, I think you just want to limit the rate of the messages, which is achieved with a [change] object.

              ok, better - except that sensor 0 - co-bangs with all sensors
              (When I touch 1, 3 or 6 - 0 prints bang as well)
              alt text
              There must be another sensorValue disrupting the flow - I tried to make this render.cpp "cleaner" but I got tons of error messages (and bela stopping)

              If someone feels like taking out the midi stuff of this render.cpp and finding two renderings of sensorValue - I would appreciate that
              https://framabin.org/p/?5d16d77f039d8958#QYF2tXlzMwCrGdw0525a0wGyhfVgd5f2zpvurT7Hr3E=

              pfewww
              I'm an autodidact - thanks for your patience Guilormo - it was truly great - I have learnt a lot!

              hey,

              I have a friend who's a crack at C and he had a look at the code of the render.cpp I had
              Here's an outline what he proposed:
              in the original code, libpd start message is at the beginning of render:

              void render(BelaContext *context, void *userData)
              {
              	int num;
              libpd_start_message(8); //get data from all 8 MPR121 pins
              	for(int n = 0; n < 8; ++n)
                  	libpd_add_float(sensorValue[n]);
                  	
              libpd_finish_list("sensorValue");
              libpd_finish_message("pd", "dsp");
              

              His proposal:
              "Try to combine the 'float' and add_float from with the code in render, and put it at the VERY END of render() but inside render, remove the for loop from readMPR121."

                  libpd_start_message(8); //get data from all 8 MPR121 pins
                  for(int n = 0; n < 8; ++n){
                      libpd_add_float(sensorValue[n]);
                  }
                  libpd_finish_list("sensorValue");
                  libpd_finish_message("pd", "dsp");
              
                 libpd_start_message(8); //get data from all 8 MPR121 pins
                  for(int n = 0; n < 8; ++n){
                      libpd_add_float((float)n);
                  }
                  libpd_finish_list("sensorIndex");
                  libpd_finish_message("pd", "dsp");
              

              OLD read at the end of render.cpp:

              void readMPR121(void*)
              {
              	for(int i = 0; i < NUM_TOUCH_PINS; i++) {
              		sensorValue[i] = -(mpr121.filteredData(i) - mpr121.baselineData(i));
              		sensorValue[i] -= threshold;
              		if(sensorValue[i] < 0)
              			sensorValue[i] = 0;
              		libpd_float("sensorIndex", (float)i);
              		//rt_printf("%d ", sensorIndex[i]); //error: use of undeclared identifier 'sensorIndex'
              		libpd_float("sensorValue", (float)sensorValue[i]);
              #ifdef DEBUG_MPR121
              		rt_printf("%d ", sensorValue[i]); //prints the values of the sensor when DEBUG_MPR121 is define at beginning of programme
              #endif
              	}
              #ifdef DEBUG_MPR121
              	rt_printf("\n");
              #endif
              	
              // You can use this to read binary on/off touch state more easily
              //rt_printf("Touched: %x\n", mpr121.touched());
              

              -----> NEW read:

              void readMPR121(void*){
                  for(int i = 0; i < NUM_TOUCH_PINS; i++) {
                      sensorValue[i] = -(mpr121.filteredData(i) - mpr121.baselineData(i));
                      sensorValue[i] -= threshold;
                      if(sensorValue[i] < 0)
                          sensorValue[i] = 0;
              #ifdef DEBUG_MPR121
                      rt_printf("%d ", sensorValue[i]); //prints the values of the sensor when DEBUG_MPR121 is define at beginning of programme
              #endif
                  }
              #ifdef DEBUG_MPR121
                  rt_printf("\n");
              #endif
                 
              // You can use this to read binary on/off touch state more easily //rt_printf("Touched: %x\n", mpr121.touched()); }

              It WORKS!
              alt text
              Also with the little piece of handwoven e-textile (80% polyester, 20%stainless steel)

              alt text
              (image is green because of curtains - heatwave)

              Latest render.cpp is here - it desperately needs a clean-up.
              https://framabin.org/p/?79ecd118364dce6a#PgFmcFomCItZkIJRkx5azj8hnZuxZs4f76OEgMIOefk=
              (you need javascript to decrypt)

              End of August - beginning of September I will write about this in full detail and post the project.

                dywen remove the for loop from readMPR121."

                hmm:

                giuliomoro proper way is to move the message sending to the render() function.

                I guess that "move" here was the key word, also

                giuliomoro IMPORTANT: are you sending something else?

                I meant exactly: are you still sending to it from the other thread (that is, readMPR121()).

                dywen "Try to combine the 'float' and add_float from with the code in render, a

                that would not work (libpd_float() and libpd_add_float() cannot be combined), and in fact it is not what you have done.

                dywen

                >    libpd_start_message(8); //get data from all 8 MPR121 pins
                >     for(int n = 0; n < 8; ++n){
                >         libpd_add_float(sensorValue[n]);
                >     }
                >     libpd_finish_list("sensorValue");
                >     libpd_finish_message("pd", "dsp");
                >    libpd_start_message(8); //get data from all 8 MPR121 pins
                >     for(int n = 0; n < 8; ++n){
                >         libpd_add_float((float)n);
                >     }
                >     libpd_finish_list("sensorIndex");
                >     libpd_finish_message("pd", "dsp");

                You don't really need to send the sensorIndex at this point, you can just assume that the elements of the list are in order. So you don't need the second message.

                libpd_finish_message("pd", "dsp");

                This line does nothing and should be removed.

                So, after removing this line and the useless "sensorIndex" message, you end up with exactly this:

                giuliomoro libpd_start_message(8);
                for(int n = 0; n < 8; ++n)
                libpd_add_float(sensorValue[n]);
                libpd_finish_list("sensorValue");

                which I sent you a few days ago.

                dywen d put it at the VERY END of render()

                This would work, but it adds one block of latency with respect to having it at the beginning of render().