Thanks for sharing this! Note, the switchramp.pd abstraction is saved as switchRamp.pd (upper case R) but in Pd it is invoked as switchramp.pd (lower case r), so Pd can't find it. Renaming it to switchramp.pd with lower case r works.

Not sure, but I guess you should have openFrameworks installed, which has a script to install dependencies. Do you have those? These scripts should also be available in Ofelia, in scripts/ubuntu.

@ben-wes is right here. the delay time to execute a ramp is the last argument, first is target and second is ramp time, just like with [line~].

No idea of the development/maintenance state of Purr Data, but PlugData, another monolith Pd variant is seriously actively developed. You might want to try that instead, unless you revert to Pd vanilla and install any externals you want through deken (Help->Find externals). IMO, that's the best option if you don't intend to use Pd as a VST plugin or want to compile your patches with heavy.

@lacuna That is correct, still, such a patch will work the same way. The [float] object can convert symbols to floats from the list-box too. Still, a good point.

There's already a new reply by the same user https://forum.pdpatchrepo.info/topic/14374/clouds-generative-lo-fi-ambient
Strange that it indeed gives some correct information and does provide a link to libPd's GitHub repo.

What @whale-av writes is correct. Also note that your first method is actually Frequency Modulation (FM) (missing the index that controls the amplitude of the modulator, of course). The second method is correct for what you want, combined with David's suggestion.

I agree. This user has two posts only, both of which look similar. He hasn't started a discussion, and hasn't offered anything really. His profile is also bot-like.

It seems that this loads when I open the All_about_else.pd patch that comes with the library. If I don't open this, even if I set the path to else with [declare], this menu doesn't work.

Is it in Pd's search path?

I think this happens when you load the ELSE library.

Even though I like Ofelia a lot, and I do use openFrameworks myself, I think the Ofelia version where it came as a single object where you could load your Lua scripts was more of a drawback, sine Pd users are accustomed to visual programming, and the first Ofelia versions that came with binaries (objects) for all sorts of stuff was more in the Pd philosophy.
That being said, together with my next-to-nothing Lua capabilities, I prefer to use openFrameworks instead. If all has to be Pd, then I'd probably go for Gem. Don't get me wrong, I was super excited when Ofelia launched, and @60Hz's abstraction brought this Gem feel to Ofelia, but I don't know why it has stopped being developed/maintained by @cuinjune. I do think that @Jona getting to take it up is also great news though.

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.