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.

@whale-av said:

@zerino Try using pdsend (a binary that is in your Pd distribution) from your script to send a message to Pd...
pd open patch.pd /the/path/to/patch/from/root
David.

$ pd open path just opens another instance.

trying with pdsend results in:

$ pdsend open /home/zerinol/fixo/pd/patches/audio_loader.pd
usage: pdsend <portnumber> [host] [udp|tcp] [timeout(s)]
(default is localhost and tcp with 10s timeout)

@KMETE

The idea that it gonna be long track of conversation as part of an installation. it could be that someone will start the track and then go away. I don't want it to run all the 20 minutes so the audio will run in chunks of time. every lets say 60 seconds (not 20) the audio will pause and if someone will press it again within the short time frame (its say 10 seconds) it will resume. if not it will be start from the beginning at next press.

OK, so the "playing" and "paused" timers actually have no interaction -- there are just two rules:

• Play: Stop when user stops, OR after x seconds
• Pause: If paused a short time, resume; if paused a long time, restart (here, btw, the [list store] idea was based on my mistaken understanding that the "resume" vs "start over" behavior depended on the duration of the last segment that was playing. In fact, it depends only on the last pause duration -- which is determined at the moment of play -- so it's a simple [timer] --> [moses] and done)

Here's my solution. (Screenshot omits a [loadbang] --> "loopx 100" -- the patch for download is complete.)

23-0219-play-control.pd

[pd play-timeout]

[pd pause-timer]

One other thing I'd like to call attention to is the liberal use of [pd] subpatches. When things get complicated, it's useful to encapsulate parts of the logic, for two reasons:

1. Less stuff in the window to get confused about. (I've seen students think "eh, a busy window is no big deal" but... if you have 10 times as many inlets/outputs visible, that's a hundred times more chances to make a wrong connection.)

2. Programming works better and goes more smoothly when the flow of information is restricted to a smaller number of paths whose meaning can be controlled and understood. It's much much easier to deal with the pause-timer and play-timeout when they are in their own windows, with only the necessary information coming in via inlets.

hjh

@KMETE said:

edit: and my reason is that if I want to do comparison of two numbers - lets say if the timer that s running is larger then constant number - if the timer will not output the numbers constantly I might miss this logic...

What you're talking about is a timeout situation -- checking whether something did or didn't happen within x amount of time.

In the normal case, in Pd, you can do a timeout like this (no [metro], no constant polling):

Here, I'm using the word "start" and "stop," but they can be any messages being generated for any reason.

• If the user hits only "start," then the [delay] time expires, [delay] generates a bang, and you know that the elapsed time >= threshold.

• If the user hits "start" and then "stop" within the time limit, then 1/ you have the trigger from the user and 2/ the [delay] gets canceled (no erroneous timeout message).

When you're talking about a timer that can pause, that complicates it a bit (because [delay] wouldn't know about the pause).

But, to be honest, based on your requirement from the other thread -- when audio playback pauses (because of user action or the 30-second(?) timeout), you're always resetting the timer. When the timer goes back to 0, then pause is irrelevant. So I kinda wonder if the original question in this post stems from an unclear requirement rather than an actual need (though it is a kinda cool abstraction, and I'll add it to my library later).

After all, if you only want to stop checking for the timeout based on user pause, you can just stop banging the [timer] at that point... then, no check, no false timeout, and no need to over-engineer. Or using the [delay] approach, just "stop" the delay.

So there's a polling timeout that is aware of paused status, without using a special pausable timer. So this idea that you have to keep banging the timing object and the timing object should be responsible for not advancing when paused is perhaps overcomplicated.

edit2: I could bang the poll message every 10ms using metro but then we again have an issue on cpu?

[timer] shouldn't use much CPU... it's probably fine, and if it's more comfortable for you, feel free to go that way. I'm just pointing out that brute force is not the only way here.

hjh

Patches from akunull:

Website:
https://www.akunull.com/piloslib/

Github:
https://github.com/akunull/piloslib

Documentation:

I use ttymidi and pd. To connect both on startup, you have to create .desktop file on rpi and .sh file
The .desktop file tut: https://learn.sparkfun.com/tutorials/how-to-run-a-raspberry-pi-program-on-startup/all

for the .sh put this code:
#!/bin/bash
ttymidi -s /dev/ttyUSB0 -v &
echo "start pd ptach"
(
sleep 2.5
echo "Connecting MIDI"
aconnect ttymidi:0 "Pure Data:0"
aconnect "Pure Data:1" ttymidi:1
) &
/usr/bin/pd /home/patch/you_folder/your_puredata_file.pd

I use ttymidi as serial bridge MIDI on RaspberryPi. Now I can use Arduino as a MIDI controller for PD.
I connect PD with Ttymidi using Patchage but when I reboot the Rpi all connections are gone. I have to connect it again. Do you know how to ‘remember’ the connection after rebooting?

@Johnny Mauser i think each visitor needs a list with which place he visited how often.
and each position of the timetable / stage matrix needs a list of the current visitors (the length of the list is the number of visitors).
or each slot of the timetable has an array(the stages) and those elements are arrays too (the visitor list).
yes, that could be doable with data structures, i used them, but not the array in an array feature - you can use arrays as elements of an array with data structures.

Theoretically you can train a neural network with this data (or you can simulate the event a thousend times for the training data), and the network can give you a result.
But i think just conditional logic makes more sense in this case, because you still would need the conditional logic for the training data...
There is actually a neural network for planning / scheduling film productions, and they said it is much faster than before: https://medium.com/rivetai/data-science-and-ai-in-film-production-8918ea654670

@Johnny Mauser I am not good in mathematics but i would start with a timetable/stage x/y matrix.
and then you can calculate the individual timetable with an expression like: go randomly to a stage at the allowed timeblock that has less visitors than its capacity if not visited already more often than possible and if visitor b is not there...
and i think you need kind of a list for each visitor which stages he how often already visited.

edit: i think the total capacity needs to be bigger than 200 otherwise it can get complicated. would be funny to see this as a pd patch.
maybe data structures are the way to go but perhaps you can instead use the [text] object.

@pepedlr Pd vanilla compiled from source on linux mint here with dependencies installed as in INSTALL.txt. i have -alsamidi as startup flag (Preferences > Startup...) and with this audio works out of the box.
For midi i have to start QjackCtl, open "Connect" and connect Pure Data Midi-Out with one of the TiMidity ports. Hope that helps?

Edit: Also have to add that my jack server is not running when i connect Pd and TiMidity.