that's actually expected: [route]
strips off the first element of the message. In your case you have a message with only one element, so it just "forwards" a bang
.
MPR121 capacitive touch and Pure Data
- Edited
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.
https://framabin.org/p/?d2e0eebe6a1f043c#MmaUCw4CZUU2L08AwD32Dg3Dk9TRG5KXQgW0jfMwYmU=
This is my translation to Pd&Bela
And it works! For the moment for pin0 on the MPR121
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");
- Edited
Of course!
But Pure data still sees them as one
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.
ha, you beat me to it!
---> https://forum.arduino.cc/index.php?topic=92793.0
Hi and hmm
it seems that unpack does not suffice - but the filtering works out well (only bangs when touched)
- 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
- Edited
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.
- Edited
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
I used your debouncer for floats (and these are not floats, of course)
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.
- Edited
ok, better - except that sensor 0 - co-bangs with all sensors
(When I touch 1, 3 or 6 - 0 prints bang as well)
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!
- Edited
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!
Also with the little piece of handwoven e-textile (80% polyester, 20%stainless steel)
(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.