Have you set it's directory to Pd's search path? Is comport installed in the externals directory? Where is it in your system?

Looking at your patch more closely, it looks like you are actually doing something like what I describe, in which case you should probably ignore my previous post.

The ultrasonic distance sensors are usually digital, not analog. If this is the case, you're trying to read a digital signal as analog, which doesn't make much sense. This sensor has two pins, a trigger and an echo. You have to send a high voltage to the trigger pin, then pull it low, and read the echo pin which will help you compute the distance based on the time it took for this trigger pulse to arrive back at the echo pin.
The code below (copied from Arduino'g Project Hub), uses Arduino's pulseIn() function, to compute the distance:

// Define Trig and Echo pin:
#define trigPin 2
#define echoPin 3
//  Define variables:
long duration;
int distance;
void setup() {
  // Define  inputs and outputs:
  pinMode(trigPin, OUTPUT);
  pinMode(echoPin, INPUT);
  //Begin Serial communication at a baudrate of 9600:
  Serial.begin(9600);
}
void  loop() {
  digitalWrite(trigPin, LOW);
  delayMicroseconds(5);
  digitalWrite(trigPin,  HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);
  // Read  the echoPin, pulseIn() returns the duration (length of the pulse) in microseconds:
  duration = pulseIn(echoPin, HIGH);
  // Calculate the distance:
  distance=  duration*0.034/2;
  // Print the distance on the Serial Monitor
  Serial.print("Distance  = ");
  Serial.print(distance);
  Serial.println(" cm");
  delay(1000);
}

I searched online and found the source of this pulseIn() function in Arduino's forum, which is this:

/*
  wiring_pulse.c - pulseIn() function
  Part of Arduino - http://www.arduino.cc/

  Copyright (c) 2005-2006 David A. Mellis

  This library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
  version 2.1 of the License, or (at your option) any later version.

  This library is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  Lesser General Public License for more details.

  You should have received a copy of the GNU Lesser General
  Public License along with this library; if not, write to the
  Free Software Foundation, Inc., 59 Temple Place, Suite 330,
  Boston, MA  02111-1307  USA

  $Id: wiring.c 248 2007-02-03 15:36:30Z mellis $
*/

#include "wiring_private.h"
#include "pins_arduino.h"

/* Measures the length (in microseconds) of a pulse on the pin; state is HIGH
 * or LOW, the type of pulse to measure.  Works on pulses from 2-3 microseconds
 * to 3 minutes in length, but must be called at least a few dozen microseconds
 * before the start of the pulse. */
unsigned long pulseIn(uint8_t pin, uint8_t state, unsigned long timeout)
{
    // cache the port and bit of the pin in order to speed up the
    // pulse width measuring loop and achieve finer resolution.  calling
    // digitalRead() instead yields much coarser resolution.
    uint8_t bit = digitalPinToBitMask(pin);
    uint8_t port = digitalPinToPort(pin);
    uint8_t stateMask = (state ? bit : 0);
    unsigned long width = 0; // keep initialization out of time critical area
    
    // convert the timeout from microseconds to a number of times through
    // the initial loop; it takes 16 clock cycles per iteration.
    unsigned long numloops = 0;
    unsigned long maxloops = microsecondsToClockCycles(timeout) / 16;
    
    // wait for any previous pulse to end
    while ((*portInputRegister(port) & bit) == stateMask)
        if (numloops++ == maxloops)
            return 0;
    
    // wait for the pulse to start
    while ((*portInputRegister(port) & bit) != stateMask)
        if (numloops++ == maxloops)
            return 0;
    
    // wait for the pulse to stop
    while ((*portInputRegister(port) & bit) == stateMask) {
        if (numloops++ == maxloops)
            return 0;
        width++;
    }

    // convert the reading to microseconds. The loop has been determined
    // to be 20 clock cycles long and have about 16 clocks between the edge
    // and the start of the loop. There will be some error introduced by
    // the interrupt handlers.
    return clockCyclesToMicroseconds(width * 21 + 16); 
}

This is already getting complicated, as pulseIn() uses other functions which should be found and translated to Pd. I guess the best thing you can do is try to translate the first code chuck in this reply to Pd, and when you read a high voltage in the echo pin, do some math to calculate the distance.
In essence, set a digital input and a digital output pin on the Bela, trigger the output pin with a high and low signal, and keep reading the input pin (you should probably use a pull-down resistor there), until you get a high. Calculate the time it took with the [timer] object and do some simple math to get the distance. Do that with distances you know first, and then use the rule of three based on the known distance and the time you get. At least, that's how I would try to get this to work.

Another solution is to use an infrared proximity sensor, which is analog, and it's probably much easier to use. But this gets the proximity of obstacles right in front of it only, while the ultrasonic range finder has a wider field where it can detect obstacles.

Thanks for sharing this! BTW, is the [!-~ 1] object inside the [pd crossfader] subpatch a typo? Should this be [!=~ 1] instead?

@ddw_music said:

@alexandros said:

It's not necessary, but if you want to not be constrained by sample blocks for the delay time, then [delwrite~] and [delread~] have to be placed in subpatches where the former will have a dummy outlet and the latter a dummy inlet,

True, but if you're doing feedback, then there's no escape from a block's worth of delay.

If not doing feedback, then the dummy inlet/outlet won't trigger errors. If feedback is involved, this inherently adds a block of delay (which can be reduced, but not eliminated, by ~block-ing a subpatch).

hjh

That's also true. To include feedback and be able to go to delays down to one sample, these two subpatches have to be included in a parent subpatch, which contains a [block~ 1]. Also, instead of [s~]/[r~] pairs, one should use [tabsend~ tabname] and [tabreceive~ tabname] along with an [array define tabname 1].

@ddw_music said:

@alexandros said:

To create feedback, you'll still need to use [s~]/[r~] etc, to send the output of [delread~] back to the input of [delwrite~]

I think that's not necessary, because there is no patch cable from delwrite~ to delread~.

It's not necessary, but if you want to not be constrained by sample blocks for the delay time, then [delwrite~] and [delread~] have to be placed in subpatches where the former will have a dummy outlet and the latter a dummy inlet, so these subpatches can be connected and the DSP order will be forced to first compute [delwrite~] and then [delread~]. It has been a subject of discussion many times, as to how to go below one sample block of delay time.

@oid is the name of the file you suggest .pd or .tcl?

That's strange. What plugdata version is this? I have 0.8.3 and hovering the mouse over [line~]'s inlet doesn't show this message. I also checked Pd's source code and [line~] is not a mutlichannel object, which could explain such a message.

The example in its help patch achieves downsamping. You might want to check out this thread https://forum.pdpatchrepo.info/topic/14648/downsample-experiment

Well, this concerns the Python script, that's why I wrote that it's not Pd related. Never mind though. What's output_socket in your code? What does it try to connect to? Did you try to print your HOST "macro"?

This is not Pd related as it concerns Python. Nevertheless, what's on line 32 in your script? The error message concerns this line where a connection you are trying to establish fails.

[hilbert~] and [complex-mod~] are vanilla abstractions located in /usr/lib/puredata/extra (at least in Linux). Have you moved them to some other directory?

Just a note that getting access to the GPIOs of the Pi is not an easy task, if I'm not mistaken. You'd be rather better off working on the Python script to smooth out the spikes, rather than trying to implement this to a Pd external.
Also, cyclone should be available for Pi 4, so why use Pd-extended that is long gone?

In Arduino you would use the pulseIn() function, where you have to toggle the trigger pin, and then get the output of this function, which you have to multiply by 0.034 and divide by 2. This should give you the distance in cm. You might want to search the source code of this function and try to translate it to Pd or some Python script that will control Pi's GPIOs.

Check py4pd too, it's available through deken. It's still beta, but it's new, so not outdated. https://github.com/charlesneimog/py4pd

@bklindgren I copied your makefile and compiled with the sources I have (I guess they are the same, since in GitHub they haven't changed in eight years), and [grambiman~] loads fine. I realized though the a [grambiman] compiles as well (no tilde), which indeed can't load. Did you forget to add the tilde character when you loaded the object?
I then changed the names of the source files, by adding the tilde character, and re-compiled. This time, only tilde objects were made. Maybe a bug of the makefile. I'll send to the Pd list or open an issue on GitHub.

I'll check when I have time and get back. Should be simple.

Automatonism is not a program, it's a set of Pd-vanilla abstractions simulating a modular synthesizer. It does nothing to the audio device, Pd itself does whatever it is that it does.
A simple way to try to debug it is to load Pd with -noloadbang. It might be that some [loadbang] is causing some issue. Sending your patch is also helpful, because all we can do now is speculate.

@bklindgren you could try to compile it yourself. It's on GitHub https://github.com/rickygraham/grambilib/tree/master
There's Makefile, but I guess you could use Pd's pd-lib-builder https://github.com/pure-data/pd-lib-builder

Drawing arrays is definitely a lot of work. If you want to constantly have your array displayed, you could use [pd~] and split the drawing process from the audio one. You can have an [array define] object in the main process that runs the audio and a graphical array in the child process. Unless you can do with closing the array window when you want to redraw, but then you won't be able to have the slider the way you show in your post.