It's just an Multi-Layer Perceptron (MLP) - a dense feed-forward neural network. Each neuron sends its output to all neurons in the next layer. Each neuron in the next layer multiplies its of its inputs by a weight. The weighted inputs are summed and added to a bias value, then passed through the activation function of the layer (e.g. a sigmoid function to ensure everything remains between 0 and 1 and don't go to +/- infinity) and passed to all the neurons in the layer after that.
It's all in the C code. If you want to learn more about this though (in case you don't know), I recommend the "Neural Networks from Scratch in Python" book, which is where I initially translated Python code to C to create this object.

@lacuna said:

For me it is hard to know because information is missing:
This part I don't understand:

and also to trigger this sample as soon as there is something echoing the trigger at a distance inferior of 15cm using a Threshold~ object

but this works already, doesn't it?
In which condition you want the sample to stop?
What kind of sensor?
What is attached to pins 11 and 12?
What data does [adc~ 12] output when moving hand?
Is [print Distance (cm) : ] about correct?
Which Bela tutorial are you referring to?

[rzero~ 1] does some integration, I think. [dac~ 11] outputs ultrasonics? [line~] till 1000 and [adc~ 12] going into [samphold~] measures the time untill the reflected ultrasound is detected or sth like that?

Generally speaking, when developing something it is important to understand what is going on instead of blind copy&paste. And when asking, to provide all information you have to make it easy / possible to answer.

Hello, thanks for taking the time to answer my question, I really appreciate it; and sorry for having missed some important information.

This patch works as it will start playback when I put my hand on the sensor, but it won't stop playback when I remove my hand from the sensor range, and I'm still figuring out how to work this out. When I remove my hand the distance keeps going up, and thus the volume, until it reaches 25cm which is the limit I've put with [min25]. Your fade out patch makes sense but I still need something to bang it when I remove the hand from the sensor, putting a Threshold at 24cm for example kind of works, but it's not completely natural; imagine you're at 5cm and remove your hand, so the volume goes up to 24cm and then stops playback...

The sensor is the HC-SR04, pin 11 send triggers to ultrasonics every 60ms, echo receives feedback and sends it to pin 12, which with a time equation calculates distance. What [adc~ 12] outputs is a good question, I try to figure it out myself too, but it doesn't work with normal [print] command, not till it reaches [snapshot~] so then it outputs the distance in cm again. The distance is quite accurate, I think the real distance is a bit longer than the printed in console. The Bela tutorials are the official ones at https://learn.bela.io/tutorials/pure-data/sensors/distance-sensor/

What I've done at the moment is sample holding and snapshotting the distance so it stays in place, so if I want to "stop" the sample I just bring the distance near 0 with my hand very close bringing the volume near 0 and nearly unnoticeable, but the playback starts from the beginning with a [loadbang] is just that at any distance you'll put your hand the volume will go up. This works well in this case as the samples are standing notes, but it would be cooler if it starts from the beginning. I know there is some way to use this sensor as a trigger but I can't find any information.

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.

@jameslo Oh, [expr~] obviously can't handle this kind of pow notation ... So what I suggested (pretty arbitrarily, to be honest) was just a skinny Gaussian curve. Try exp(-1000*$v1*$v1) instead.

The intuition behind my choice was quite simple: First off, I thought it might be useful to reduce the density of the echoes of the input sample. In fact, convolution does produce "echoes" at every sample, although most of them won't be heard as echoes but as filtering effects. Furthermore, the exponential function has the useful property to be bounded between 0 and 1 for negative input values, and it seemed to be a natural choice, since it corresponds to our perception of amplitude.

Trying to generalize on how to use a transfer/shaping function in this specific case: The input (noise) is equally distributed, so the distribution of the output will be exactly the same as the distribution of the shaping function itself. If I correctly understand the concept of white noise, any shaping function will also produce white noise as its output. The "color" of noise is only affected, if the operation introduces some kind of correlation between successive samples. That's what all digital filters do, of course. So now you may ask: Then why does waveshaping in its conventional use affect the timbre of a sound? Well, usually successive samples of an input signal aren't uncorrelated, right? A transfer/shaping function then will have some impact on the existing autocorrelation of the sound. So the case of applying such a function to white noise is really quite specific.

BTW: Thinking about distributions of sample values also helps to understand the RMS amplitude of differently distributed white noise signals: Equally distributed noise has the same power as triangle and sawtooth waves, whereas binary noise has the greatest possible power, equal to square waves etc.

Hopefully, this does help in some way ... Apart from that, I would recommend to implement the transfer function as a lookup table and draw different curves. I think, this might be the best way to get an intuition of how a waveshaping transfer function works.

Edit: Drawing the histogram instead of the transfer function may be even more intuitive, especially if you already know how to use [array random]. So here's basically an audio rate version of that ... array_random~.pd

@Zooquest You will hear clicks because there will be jumps between samples.... if the playback was at a sample level of 0 and you change the delay time to a point where the level is 1 then the click will be loud.
You will hear "steps" as the playback point is probably being changed repeatedly by the ctrl messages.

You could experiment with a [lop~] filter in the delayed sound output, with a high value e.g... [lop~ 5000] but you will lose some high frequencies in the echo.
That might sound natural though, like an old tape echo, but you will probably still hear the clicks a little.

Or you could "duck" the echoes by not changing the delay time immediately, reducing the echo volume to zero in say 3msecs using using [vline~] and not bringing the echo volume back up to 1 (in, say, 3msecs again) until you have NOT received a ctrl message to change the delay time...... for again 3msecs.
The last part of that would need a [delay 3] using the property that any new bang arriving at its inlet will cancel the previously scheduled bang.

You would need to duck the FB signal as well though, and all that that might sound worse than the [lop~].

I cannot remember well...... but this "sampler_1.pd" might contain elements useful to demonstrate "ducking" https://forum.pdpatchrepo.info/topic/13641/best-way-to-avoid-clicks-tabread4/12

Or do a crossfade between separate delays once the incoming control messages have stopped..... https://forum.pdpatchrepo.info/topic/12357/smooth-delay-line-change-without-artifacts ..... as you can then avoid the "duck"ing effect.
David.

@zerino You need a patch open with a [netreceive] object in it and connect the left outlet to a [s pd] like,

[netreceive 3000]
|
[s pd]

Then from the command line you send a command like echo open filename.pd $(pwd)\; | pdsend 3000 and it will open filename,pd, this assumes you are in the directory which the file is in, the $(pwd) command can be replaced by a path. You should be able to setup your file manager to do all of this automatically but I am not familiar with if, or an alias in your .bashrc or the rc of whatever shell you use, for bash alias pdopen="echo open $1 $(pwd)\; | pdsend 3000"

Edit, we can not actually use an alias like that in bash, but we can make that a function, just put this in your .bashrc instead of the alias. Need to run source ~/.bashrc in any open terminals or logout/log back in for it to be usable. Then just run pdopen <filename> and it should work.

function pdopen () {
   echo open $1 $(pwd)\; | pdsend 3000
}

I will check it late on my mac computer. for the moment I'm not on my computer, so I don't want to waste much time on it now as I think it will work on my computer.
For the moment I'm using your help file patch which is great. Your abstraction is so much more easy to use then from my patch I shared in the beginning.

what I'm trying to do is the following -
I will have 8 different sound files. Each sound file should be in a individual sf-play2~ object.
I will have data from 8 diffrent sensors I'm reading via arduino. Each sensor will report 0 or 1 (if sensor is pressed or not) alongside with analog data of numbers between 0 - 1023.
What I would like to do is that when I'm reading 1 the audio file will play, when reading 0 the audio file will pause . if 1 is held and the audio file arrived to it ends it will continue from the beginning. (loop 1) . I will also have a clocker to report how much time has elpased since sensor is 0. If more then x seconds the audio file will go back to beginnnig so next time sensor is held (1) it will start from the beginnnig.

here is my try with your abstraction.
the green part is to imitate the on off from the sensor. the blue is the analog data from sensor.
the orange part is my try to make a clocker that will start count when sensor is off. The yellow part is for small envelop to avoide clicks when audio is pause and resume.

How can I make the audio file go to the beginning when the orange part is reporting a bang (that time was elapsed) ?
Also - I'm not sure if the yellow section is working. Meaning if it is indeed making an envelope on every pause and resume ? Is that possible?

sfplay~example.pd

Thanks!

edit: the scale of the sensor should be inverted. 0 1023 0 1

edit 2: how can I make the sf-play2~ go back to the beginning of the audio file without starting it immediately?

edit3: how can I load the file to the sf-play2~ object without starting it? if I don't press "all" message it won't load the file. I would lik the file to be loaded to the beginnnig, but to start and play only when receiving data from sensor on off. for the moment if I'm not pressing all message the file won't play.

@Riccardo-V I am no mac expert. Looking around the web I think you need backslashes in your path..... so
cd Users\Riccardo\download\pd-0.53-0
... and then you should have Users\Riccardo\Downloads\pd-0.53-0\mac at the command prompt.
Then type make and enter.

Pretty sure that you did enter edit mode and return to run mode on the second selection of the edit button...... as the cursor changed in between. Edit in the title means that you have modified the patch..... and will disappear when you save it.

The echo sounds to me like one button press on the keyboard...... but how or why it is being repeated from the speakers I cannot say.

Ventura does seem to still have some bugs..... maybe going back to what was before will be the most certain method to get you working again.
David.
Edit...... the sound from Pd seems to be working. It turns on and off as you change numbers in the patch. That echo must be coming from some other program I think... or a feedback loop within the Ventura audio settings.

@ddw_music
is it similar to --- in MaxMSP ?

and where I have echo-del2 I should call it echo-del2-$0

?

@KMETE said:

What is the best method to have 5 copies of the same patch but each patch should be load with a different audio file.

"Multiply defined" error means, add $0 to object names. (It looks like multiply like a * b, but it's really "multiple-ly defined.")

That is, where you have echo-del1, call it echo-del1-$0.

The $0 gets replaced by a unique number for every load. It's an important technique.

If it's me, I would have only one comport and then route according to incoming data.

hjh