Hi, I’m possibly doing things completely wrong - but I’m running out of ideas and was hoping to maybe get some help here. I’ve successfully installed the pd2dsy tools for Windows and with the pod config, I also manage to flash stuff on my seed and it works and sounds great! Thank you so much for this beautiful project!
I then planned to connect an MPR121 sensor for some control signals. But this is where I’m stuck now. I wanted to test with a very simple json config like this:
But when I run python pd2dsy.py --custom-json sym.json patches/sine.pd, it fails in the end with the following report (only copying the first few lines of the errors here):
In file included from HeavyDaisy_sine.cpp:35:
source/HeavyDaisy_sine.hpp: At global scope:
source/HeavyDaisy_sine.hpp:128:10: error: 'Mpr121I2C' in namespace 'daisy' does not name a type
128 | daisy::Mpr121I2C touch_sensor;
| ^~~~~~~~~
source/HeavyDaisy_sine.hpp: In member function 'void json2daisy::DaisySym::Init(bool)':
source/HeavyDaisy_sine.hpp:50:12: error: 'daisy::Mpr121I2CTransport' has not been declared
50 | daisy::Mpr121I2CTransport::Config touch_sensor_config;
| ^~~~~~~~~~~~~~~~~~
...
It looks like there should be a simple solution to this since it’s obviously related to missing definitions. Any ideas how to get this running? Thank you!
The version of libDaisy included in the main branch of pd2dsy is a little out of date now, so the MPR121 device isn’t included in there. As long as you have git, you should be able to update your libDaisy (open up pd2dsy in the terminal, run cd libdaisy, then git pull origin master, and finally make.
Thanks a lot for your support! Pulling the updated libdaisy and make worked for me. The result looks different now - but unfortunately, I’m facing a new error now. Seems like I need to forward the pins in some other way?
In file included from HeavyDaisy_sine.cpp:35:
source/HeavyDaisy_sine.hpp: In member function 'void json2daisy::DaisySym::Init(bool)':
source/HeavyDaisy_sine.hpp:53:44: error: no match for 'operator=' (operand types are 'daisy::Pin' and 'dsy_gpio_pin')
53 | touch_sensor_config.scl = som.GetPin(11);
| ^
In file included from ../libdaisy/src/daisy.h:5,
from ../libdaisy/src/daisy_seed.h:5,
from source/HeavyDaisy_sine.hpp:29,
from HeavyDaisy_sine.cpp:35:
../libdaisy/src/daisy_core.h:260:8: note: candidate: 'constexpr daisy::Pin& daisy::Pin::operator=(const daisy::Pin&)'
260 | struct Pin
| ^~~
../libdaisy/src/daisy_core.h:260:8: note: no known conversion for argument 1 from 'dsy_gpio_pin' to 'const daisy::Pin&'
../libdaisy/src/daisy_core.h:260:8: note: candidate: 'constexpr daisy::Pin& daisy::Pin::operator=(daisy::Pin&&)'
../libdaisy/src/daisy_core.h:260:8: note: no known conversion for argument 1 from 'dsy_gpio_pin' to 'daisy::Pin&&'
A short update here after some more (quite clueless) guessing and experimenting:
It compiles after I remove the part for the scl and sda config from the map_init string of the json: {name}_config.scl = som.GetPin({pin_scl});\n {name}_config.sda = som.GetPin({pin_sda});\n
If I see it correctly, the definitions in mpr121.h default to the pins that I tried to set anyway (which sounds reasonable):
scl = Pin(PORTB, 8);
sda = Pin(PORTB, 9);
… which is the same as the definitions in daisy_seed.h for 11 and 12:
I couldn’t try this yet on the daisy since I’m currently not at home - but I assume it might actually work then. Might still be nice to have the pins more easily configurable, of course.
I also tried to replace the part of the map_init with specific pins like this, which also works: {name}_config.scl = daisy::seed::D11;\n {name}_config.sda = daisy::seed::D12;\n
Good news: the functionality with r touch_ch0 @hv_param to r touch_ch11 @hv_param works perfectly now!
Bad news: when I try to get a smoother signal with r touch_ch0_raw @hv_param to r touch_ch11_raw @hv_param, I get really weird results and it seems to me like there might be some stuff configured wrongly in the mpr121 configuration (or in my specific cheap DollaTek sensor maybe?):
I have all 12 channels connected to the volume of specific sound sources here (currently just a simple test with chromatic phasor~ sources). With the above version, I can turn them on/off (1 / 0) by touching them (with a touch_threshold set to 4 in my case). If I use the raw version, I should get values of 0..1024 according to the readme of GitHub - electro-smith/pd2dsy: Utility for converting Pure Data (Vanilla) patches to Daisy projects.. Unfortunately, what I get is this:
all receivers (r touch_ch0_raw @hv_param to r touch_ch11_raw @hv_param) seem to get the same messages
the value of these messages seems to correlate with the index of the pin. ch0 triggers low values whereas ch11 triggers higher values (same with the channels inbetween)
there is no resolution in these signals - they’re either on or off
Well I’m glad you got the pin selection working! The original method for choosing pins with pd2dsy has been deprecated in libDaisy for a while now, and it looks like it’s finally been removed. Sorry for the confusion!
As for the MPR121, I’d have to take a look at the source code to see what might be going on there. It might be that the _raw variant is misconfigured in some way.
So I double checked the code, and it actually seems to check out just fine. It calls the method that fetches the full 0-1023 readout, and it should be passed along to pd no problem. Does the datasheet for your chip say it can do full 16-bit readouts of each channel? And what are the exact values is produces?
Sorry for not replying earlier to this and thanks a lot for checking the code! I had a video prepared to demonstrate the current behavior - but eventually, it didn’t seem too useful to me and I planned to make another one. Then holidays arrived and I was a bit distracted. So … happy new year first of all!
I tested with 3 different Mpr121 - two of them are these cheap models: https://www.amazon.com/dp/B07MPB41MB … and the 3rd was another almost similarly cheap version (looking almost similar also). Unfortunately, I don’t find specs for them to check about these 16-bit readouts. And about the exact values: Debugging Pd on Daisy is probably only possible with some kind of debugging sound output? Or is there any other way for me to obtain exact values?
I’ll make a demo video in the next days trying to make the sensor data audible in some meaningful way. But if the raw data won’t work, I’ll just stick to the simple touch triggers for now (or maybe also test with another, less cheap Mpr121 version - maybe Adafruit or sth?) …
hi @ben-wes, i think i’m running into the same issue as you here as when i’m trying to compile (in plugdata) i’m getting an error that the scl pin i’ve addressed in my custom json is not recognised.
when you say “It compiles after I remove the part for the scl and sda config from the map_init string of the json:” which json file are you talking about? i’ve located the mpr121.h file bit i can’t find that string in there. Any help most appreciated!
hi @crewdson! … unfortunately, I didn’t document my experiments very well and also switched systems from Windows to Mac a few weeks ago (and don’t have the previous Daisy projects set up here right now). But iirc, the changes I mentioned above are about this file (which I think should be part of the pd2dsy installation):
Do you see this component_defs.json file somewhere in your plugdata setup?
Good luck!
This is part of the Toolchain, but it shouldn’t be necessary to edit this file though. Are you sure you had to make modifications to this file in order to use the component? Then we should send these changes upstream so that everyone can make use of them.
I had to make changes to make the mpr121 work for me, yes (work partly at least - since I never managed to get useful raw data and gave up on this for now). I’m not sure if these would be the same changes that someone with an actual understanding of the whole toolchain would make though. With my first suggestion, the pins would always fall back to the existing definition, not allowing manual definitions in a custom json anymore, I think - which doesn’t really sound like an ideal fix unfortunately.
During my experiments, I also got the impression that my mpr121 components were really crappy, which made actual debugging hardly possible since they gave me different results with what was supposed to be identical hardware (including identical jumper settings).
So … happy new year first of all!