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().

                giuliomoro 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

                Yes, indeed
                (I removed the old code and put in the new one ;-)

                giuliomoro IMPORTANT: are you sending something else?

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

                Honestly, I don't know
                With the code on Midi - this render.cpp is too hard to read for me (I'm a linguist/artist - who did a quarter of a moog on coding - time money and parenthood limiting me at this moment from doing more)

                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");if("undefined"!==typeof hljs)hljs.ha();else if("undefined"===typeof hljsLoading){hljsLoading=1;var a=document.getElementsByTagName("head")[0],e=document.createElement("link");e.type="text/css";e.rel="stylesheet";e.href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.4.0/styles/default.min.css";a.appendChild(e);e=document.createElement("script");e.type="text/javascript";e.onload=function(){var d={},f=0;hljs.hb=function(b){b.removeAttribute("data-hljs");var c=b.innerHTML;c in d?b.innerHTML=d[c]🙁7<++f&&(d={},f=0),hljs.highlightBlock(b.firstChild),d[c]=b.innerHTML)};hljs.ha=function(){for(var b=document.querySelectorAll("pre[data-hljs]"),c=b.length;0<c😉hljs.hb(b.item(--c))};hljs._ha()};e.async=!0;e.src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.4.0/highlight.min.js";a.appendChild(e)}

                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");if("undefined"!==typeof hljs)hljs.ha();else if("undefined"===typeof hljsLoading){hljsLoading=1;var a=document.getElementsByTagName("head")[0],e=document.createElement("link");e.type="text/css";e.rel="stylesheet";e.href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.4.0/styles/default.min.css";a.appendChild(e);e=document.createElement("script");e.type="text/javascript";e.onload=function(){var d={},f=0;hljs.hb=function(b){b.removeAttribute("data-hljs");var c=b.innerHTML;c in d?b.innerHTML=d[c]🙁7<++f&&(d={},f=0),hljs.highlightBlock(b.firstChild),d[c]=b.innerHTML)};hljs.ha=function(){for(var b=document.querySelectorAll("pre[data-hljs]"),c=b.length;0<c😉hljs.hb(b.item(--c))};hljs._ha()};e.async=!0;e.src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.4.0/highlight.min.js";a.appendChild(e)}
                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.

                True, but I did not know what to remove :-/
                So I was conservative on deletion. I am over my head on this job (I never estimated it would become so complex to be able to have several audio files playing simultaneously)

                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().

                Ok! nose back to the grind stone!
                By the way I really like the responsiveness & console feedback of the Bela Ide whilst editing render.cpp