• alexandros

    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.

    posted in technical issues read more
  • alexandros

    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.

    posted in technical issues read more
  • alexandros

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

    posted in abstract~ read more
  • alexandros

    @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].

    posted in technical issues read more
  • alexandros

    @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.

    posted in technical issues read more
  • alexandros

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

    posted in tutorials read more
  • alexandros

    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.

    posted in technical issues read more
  • alexandros

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

    posted in technical issues read more
  • alexandros

    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"?

    posted in technical issues read more
  • alexandros

    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.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!