Hello, I want to send an array (1) from my main patch, to another array (2) that is within an abstraction, replacing the contents of array 2 in the process.

I want the size and the range of array 1 to also overwrite those properties of array 2, so that I can drop an array of any size and range into the master patch.

I have so far managed to overwrite the size of array 2 using [array size array-1], which allows you to get and change the size of an array, but I cannot find the equivalent for the range property. The [array] object has a couple of arguments, 'min' and 'max' that I thought might help, but they get the min and max values from the data in the array, not the actual min and max range from the array properties.

Does anyone know if there is a way to get min and max range properties from an array, and then set those properties to another?

Sorry just wasn’t sure if the images uploaded properly. Doing it from my iPhone so not used to how it looks

* Hi everyone 
I have searched around, I found any solutions that match my problem or are up-to-date unfortunately.

I’m having trouble unpacking and/Or routing the data coming in from sensors attached to my Arduino uno. The senses are working fine when I check the Arduino serial monitor before I began looking at the PD patch.

I just can’t seem to get them to unpack, or route in PD 0.5

Just wondering if anyone else has solved this - or has found this to be a problem?

Attached are images of two separate Arduino Scripps I’ve tried. One to try unpacking, the other to  try routing - Plus, an image of my pure data patch to try testing the incoming signal data.

![Arduino-Sensors Input-Unpack.png](/uploads/files/1729806028184-arduino-sensors-input-unpack.png) [sAp-Sensors Input Test.pd](/uploads/files/1729806028183-sap-sensors-input-test.pd) ![sAp-Sensors test-pd Image.png](/uploads/files/1729806028184-sap-sensors-test-pd-image.png) ![Arduino-Sensors Input-Route.png](/uploads/files/1729806028179-arduino-sensors-input-route.png) 

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.

I was hoping to build a variable-speed sound file streamer abstraction -- like readsf~ but with a rate inlet (particularly for correcting a mismatch between the file's sample rate and the DSP sample rate).

I was hoping to do it like this:

• Allocate an array with x frames.
• Upon "cue," load x/2 frames at the beginning of the array.
• When playback takes off from frame 0, load the next x/2 frames into the second half of the array.
• When playback crosses the halfway point, load the 3rd x/2 chunk into the beginning of the array.
• At this point, then, a phasor can just read forward through the array, and loop back to the beginning. At every half-transition, load data into the half of the array that isn't being played.

I quickly run into gaps in soundfiler's interface.

• "-maxsize" resizes the target array -- there appears to be no way to load partially into an array.
• There also doesn't seem to be any way to read starting at index 'a' in an array. "-skip" will skip frames from the file, but there isn't a flag for where to start putting data into the array. (Compare SC, with parameters fileStartFrame, numFrames and bufStartFrame for the buffer read message.)

This was to distribute a multichannel fixed-media work. I was thinking Pd because the download size is small. But I think I'm going to have to take this back to SuperCollider because there's a VDiskIn built-in -- can just use it, not spend time hacking it.

In any case... are there any workarounds for those two limitations? (I guess I would need two arrays -- I was hoping to avoid that because switching the table name sample-synchronously also sounds a little bit tricky.)

hjh

Great thanks-- I'm going to type out and share my process here in case anyone else is curious or has similar issues in the future.

I've gotten a Raspberry Pi 4 Model B to read distance in cm from this script here (https://tutorials-raspberrypi.com/raspberry-pi-ultrasonic-sensor-hc-sr04/)--

At this point I am going to try my hand at converting this script into a PureData object. After that I will try to use those values as an amplitude variable to send out to [dac~]. One foreseeable issue is that there are pretty dramatic value spikes in the python code when you move an object in front of the sensor (e.g. it will read 30cm, 1207cm, 11cm).

I'll report back later after a bit more digging.

** mini-update

I had to reset to RaspberryPi OS and manually install puredata extended 0.43.4 using this guide here (https://puredata.info/docs/faq/debian). From there I managed to get the cyclone extension to work but not py4pd--trying to figure out a workaround.

@Load074 Over the past few years I've also been trying out various approaches along the lines of what you're looking for, and actually tried something rather similar to your idea: pulling only one sample per x samples of the source array and sending to a smaller display array. And indeed, it doesn't work because those values are just scattered snapshots of the signal & will be discontinuous with the neighboring display samples. I realized that some kind of averaging would be needed, started to work on it, then got sidetracked & never followed through...

But, I ended up finding two pre-baked solutions:
rh_wavedisplay from netpd
pp.waveform from AudioLab

I can't quite wrap my head around how rh_wavedisplay works from looking inside the abstraction, but the result looks nice. From the help patch:
This abstraction finds the minima and maxima for each section of the source table that covers one pixel of the display array. The result is a good looking waveform that does not suffer from aliasing.
I also like that it allows for only a section of the source array to be used for display (which is important for how my performance patch uses arrays). In practice it still causes audio dropouts when updating large source arrays, unfortunately.

pp.waveform uses data structures, which is why the result looks so different visually. I don't understand data structures enough to play around with this or try to adapt it for my uses, but I would be definitely curious about whether it's any more efficient than those other graphical array manipulation methods.

I also wonder if there's simply no method that will prevent audio dropouts without some kind of array manipulation that can run on a different thread. I've been looking into the shmem library to see if it's possible to outsource the array processing to another Pd instance (similar to the Pd~ approach that @alexandros suggested), haven't gotten very far so I still don't know if there will be a bottleneck when dumping a huge array to memory.

hello! this question intersects with Pd even if it is not about Pd specifically...
I currently have several (installation) pieces in which the sound is run from Pd and then I have motors or sensors being run off other things.
This means that in one case I am using a raspberry pi for the Pd part and an Arduino mega for the motor part
In another case I have Pd running on a Bela/BBB and then an Arduino doing the motor stuff.

The reason for this inefficiency is that my knowledge is fairly limited on these platforms. However, it is annoying to have to use the extra gear when I don't have to. Especially because I know that both the raspberry and the Bela have pins that could be used in place of the arduino for this purpose. Since the Bela is a simpler case and the pins can be addressed directly from Pure Data, I will ask about that and leave the Raspberry behind for now (as I think I would end up running Pd AND Arduino on that board anyway, whereas with Bela, one can easily address the pins from inside Pd without any other programs or libraries).

My question is this: does anyone know how the standard mappings of pins Analog/Digital/and PWM pins on the Arduino lines up on the Bela? Does the Bela have have PWM pins like, for example pins 8,9, 10,11 on Arduino Mega or Dueminanove? And if so, what is the best way to address them from Pure Data? Basically, I'd like to convert my already very simple Arduino sketches over to Pd, so that both motors and Audio can run from the same patch.

I know this isn't specifically a Pd issue but I have asked a related question on the Bela forum but didn't get an answer so I hoped someone might know or be able to suggest a resource over here...
I have traversed the Bela documentation already of course....and will continue with that meanwhile.

Jorge

@esaruoho So you don't really want to move it....... you are still looking for a way to have a constant update (while it is actually updating).
Some messages will update the [array] as @oid says..... and there are many......... https://forum.pdpatchrepo.info/topic/10720/change-appearance-of-an-array-by-sending-a-message

But there is only one message that will do so without changing the data or the appearance.....
[;
arrayname rename arrayname(
....... renaming the array with the same name will cause a redraw.

I am a bit loathe to point you in these directions as it will create more fun.....

When an array is updated Pd will send a ping message..... that could be used to update again, but maybe a small delay would be advisable (feedback overflow)..... https://forum.pdpatchrepo.info/topic/11501/get-array-values-when-they-are-updated
For [array define] a copy can be created for display...... could also be done with a [metro]...... https://forum.pdpatchrepo.info/topic/12072/display-an-array-define-array-constantly
But too fast updating will cause dropouts.
David.

@whale-av said:

@esaruoho The chance that you will always catch the start point is not great.
I would suggest a pre-roll...... so press the toggle before the sound is played and then you will not miss it.

unfortunately this is simply not possible. i work with a friend and they play whatever at any point in time and it's up to me to pick up the pieces and get tons of happy accidents. but surely metro 2000 is not precise enough, maybe i should change it to metro 1000? or is it a case of by the time an array visually updates, it is already recording more to the array?

i found that with the 1mb array, it does not visually update until the whole array has been recorded, so you don't see "content appearing in the array during the record".

i'm not at all sure now how to take a specific segment of an array and copy it to another array, because it seems that [array sum startpoint + specificlength + arrayname] isn't what i'm looking for. or am i mistaken? i couldn't seem to find an example from the help. EDIT: well it helps to be using [array get] instead of getting confused with [array sum] documentation which is something else altogether

You can use a slider for finding the start point,

i'm not 100% how that would visually look like though, i mean, is it possible to visually show that "this is where the startpoint is at? should i have two arrays, with one being controlled by the slider, and one with the audio content?

my array is X size 600 and Y size 90 - so pretty huge and wide. i guess i should make a 0 to 1048580 slider and hope for the best?

and use [lop~] to "scrub" which should make that easier..... https://forum.pdpatchrepo.info/topic/11850/explanation-for-lop-object-in-this-patch-requested

thanks, i'll have to study this, since it seems very interesting.