right, that's because of the duplicated scope.setup() lines. Remove the scope.setup(2, 44100) from the fourth line of setup(). Also, remove these lines from the top of render():
// Logging to the scope the pulse inputs and the distance
scope.log(digitalRead(context, n, P8_08), distance/100);giuliomoro Thanks, still not getting audio or printed messages in the console 
giuliomoro Nevermind, I had the wrong object name in Pd, getting it printed in the console now 
thanks for all your help - I'll give you a buzz if I need anymore help. Is there a donate function on the Bela website?
wow! no donate function yet, but I guess you can buy some expedited shipping if you are so inclined ! https://shop.bela.io/expedited-shipping
giuliomoro Haha, cheers I'm going to have a crack at implementing a second sensor and Pd object for it, thanks for giving me confidence with C++
good luck, let us know if you are stuck somewhere
giuliomoro Hiya, back again 
I've attached two sensors now, with the second sensor attached to:
GND: P08_01 Ground
ECHO: P08_10
TRIG: P08_09
VCC: The pin next to (horizontally) P09_07
I've duplicated the variables at the top of the C++ file:
and made the duplicates and changes to the setup:
and duplicated the render part:
Here is my new Pd patch:
but as you can see, the console is printing the same number for both sensors. I get the feeling I've done something wrong with the render part...
You also need two separate PulseIn objects.
Just now you are initializing the same object twice, with the second call to init() probably overriding the first one, so you currently are only monitoring the second sensor.
giuliomoro Got it, thanks, I overlooked that. Now its working but the console is updating every 1 second or so, instead of the constant stream of data like it was before, any way to fix that?
giuliomoro Ah, its not actually, its just scrolling up the window and not staying at the bottom of the console window. Interesting..
That may be due to the zoom of the browser tab containing your IDE window not being 100%.
giuliomoro Yep I zoomed out for one of the screenshots haha
https://github.com/BelaPlatform/Bela/issues/275
Or maybe try to clear the console manually (with the button or cmd-k or ctrl-k).
I have a full PD solution for this if you're interested
https://github.com/5un/bela-ultrasonic-distance-pd
(Connection is all like in Bela's official c++ example)
soravis I have a full PD solution for this if you're interested
Brilliant! What is the purpose of the [metro] banging the [print] ?
If @sambilbow was interested in a similar solution, be advised that this is using the analog outputs ([adc~ 3]) so you will have to change it to use the Digitals.
Incidentally, @sambilbow: did you need an external transistor to amplify the 3.3V to 5V to trigger the HC-SR04 or did it work straight from the 3.3V ?
giuliomoro
The [metro] and [print] was totally unnecessary and it's just for logging out the current distance from time to time. In terms of power source, I feed HC-SR04's vcc with Bela's SYS 5V like advised in the C++ example.
giuliomoro It worked straight from the digital outputs I connected it to. !
By the way, the patch is going well now, I'm just fiddling with some Pd at the moment. I've come across a problem where if i stop the patch running in the IDE before a solenoid has received a 0 message, the solenoid will stay ON, causing it to get very hot (burnt one out yesterday) (its also connected to 12v). Is there any sort of reverse loadbang? where I can bang 0 to all solenoids upon closing the patch (stopping the IDE). I saw the bottom section of the render.cpp and it seems that would be the place to put it, but I'm not sure...
There is no such possibility unfortunately, though you could implement it using a custom render file.
However, if your program was to crash, then there would be no way for it to terminate gracefully. Also, no one would prevent you from having a bug in your code that would cause a similar behaviour while the patch is running.
Generally speaking, it is often best to have a software-proof hardware, so that any bug or unexpected behaviour of the software will not cause a hardware failure. In your case, as you are making a percussion instrument, you may want to have a high-pass filter to provide AC coupling between the digital output and the mosfet, so that the solenoid is only triggered on a positive voltage change and it never sticks "on".
I think I've fixed the problem, the delay between the 1 and 0 message was way too long, and now I make sure there is nothing within my operating range on the sensors (5-45cm).
But, as always, I have a new problem . Well, not exactly a problem, more of an oversight. I didnt realise how much of a flat surface has to be used for the sensor to 'hear' the echo back. After a long time looking at my code, wondering why suddenly sometimes all of the solenoids actuate, I realised it was because when the sensor doesn't receive an echo, it panics and sends an output to some or all of the solenoids, causing them to turn on (I think its something to do with Bela as I get a block dropped when it happens. Normally what happens is there is a massive spike in the distance received which is normally 5-45cm, so it spikes 300 or something, and then block dropped, and then the solenoids panic actuate... My pure data patch has conditions in it, so that the only time the solenoids actuate should be when the distance is between 5-45cm, this leads me to believe that its a bela/cpp problem).
On an unrelated note, I've just Run the project and nothings working??? No print data going to the console, no solenoids reacting to the sensors. I made a test metro-print patch, and its not printing anything to the console. I've tried unplugging, ejecting the SD card. Any ideas?
Thanks for any help
https://i.imgur.com/X1YTxGb.jpg This works
https://i.imgur.com/F4d8hES.jpg This angle sometimes fails to return the signal to the sensor causing Bela to panic
