@flight453 i have made an abstraction for this, feel free to use as you like. velocity-senitivity.pd just download it and call it in your patch.

when you call a patch (or any normal file) in pd through directory traversing in objects, there are some rules (idk if i know all, because i have just stumbled upon them randomly):
a: to call a patch in the same directory (folder) as your main patch, just type out the name, excluding the ".pd" at the end, so velocity-senitivity.pd becomes velocity-senitivity.
b: to call a patch inside a directory which is inside the same directory as your main patch, just type the directory name for the directory inside the shared directory, then a "/" and then the filename, again, excluding ".pd", so velocity-senitivity.pd inside the directory "abstractions" which shares the directory with your main patch, becomes abstractions/velocity-senitivity. you can go as many directories in as you like, so abstractions/midi&more/velocity-senitivity
c: if it is outside your directory type one "." for as many directories you have to go outside and then "./" (yes, that is a "." followed by a "/") and then your patch name, again, excluding ".pd".
d: you can type what rule "c" says and not entering the patch name, and then type what rule "b" says. here's an example of this in action .../abstractions/midi&more/velocity-senitivity, so the ".../" means that you shold go back 2 directories, and "abstractions/midi&more/" means that you should go inside the folder "abstractions", and then "midi&more", and "velocity-senitivity" is the the patch that you want to use.
e: just typing out the full directory, again excluding the ".pd"

you'r welcome

@Joseph-Mikkelson No, changing the samplerate will not help, except that matching it to the soundcard reduces the load on the cpu......but there are more important issues...... see below.....

I should have expanded on latency.
Using a live input [adc~] and doing some Pd processing effects and then sending that to speakers [dac~] latency is not so much of a problem. Often it involves delays anyway (echo, reverb, etc.) and our ears are used to that.
Latency for playback of an audio track, or generated audio, is no problem...... it is heard when it arrives at the speakers and that is all.
Problems arise when the input goes straight to the output....... as with a monitor mixer built in Pd for example..... with live acoustic instruments...... where the musician hears their own instrument acoustically and the same sound delayed in the monitor. Essentially a chorus effect is produced, caused by the latency, and that will make it harder for a violinist for example to pitch correctly.
Chorus in a reverb effect really upsets violinists..... anything much over 5ms.
Of course a massive latency...... 100ms+..... will cause timing problems even for a guitarist, and even if they are the rare musician that didn't have such issues in the first place.
I have met classical and jazz musicians that have learnt to dissociate what they play from what they hear...... for example playing through a delay, but in sync with everyone else...... so playing say 1 second before everyone else....... but......

SAMPLE RATE
You should match your samplerate to your soundcard, or you will have re-sampling artefacts....... usually a low level high pitched whine when your patch is not producing any sound.
It is slightly more complicated than that.
If you play an audio file that was recorded at 44.1KHz while the Pd samplerate is set to 48KHz it will play back at the wrong speed....... Pd will not resample it and so the pitch will be wrong.
It's a PITA.
So the Pd samplerate must be set to match all the audio files that you use in Pd.
To avoid the artefacts you then need to set your soundcard to match Pd.
Other programs will adjust..... so that is not a problem.
External cards can make that change through their control panel, and internal cards should have the option somewhere.
In windows it is here in the speaker control panel..... https://forum.pdpatchrepo.info/topic/12094/newbie-clipping-on-pure-data-portable-with-mmio/4
and I am pretty sure that windows always sets the on-board soundcard to 48KHz "out of the box".
David.

Hello,

I am working on a Sound Installation for a special Education School. The Installation is going to be located in the Snoezel Room (a room with a soothing and stimulating environment). So the basic Idea is, that you can press a button (or another input device like IR ... still working on this) and then a "Star" (Led lights at the ceiling) turns on and a corresponding sound is heard. The light is supposed to fade together with the sound. To be able to achieve this I want tu use a Bela that runs a PD Patch and controls the LEDs. So right now I am still working on the basic Patch, that has to be PD Vanilla (because of Bela). Right now I am working with 8 "Stars" and when you press a button (right now on a midi Controller) it starts an ADSR Envelope that controls a Bandpass Filtered noise sound. You can chose different scales like Overtones, Pentatonic, .... . Additionaly I have added atmospheric sounds like water and waves/wind to create a soothing atmosphere. What I want to do now (and where I do not know how to achieve this) is:

1. I would like to integrate a Loop Function, that saves all the Input Data (Numbers and the Time when they are triggered). It should start to record the Data when the first Sound is triggered and then when there was no Input for a certain threshold (like 5 - 10 sec) it should play back the recorded Data in a Loop.

2. For the Atmosphere I also would like to add a soothing tonal drone that fits the Sound of the Scale of the Resonating Noise. I tried something with a phasor~ an long attack and release and a bit of filtering ... but it really does not sound good and soothing now. Any suggestions on how to get an atmospheric soothing slowly changing drone like tonal sound would be of big help!

@Maggie17 Sometimes it is easier with words........

Dollar $ variables in Pure Data patches.
A dollar variable is a thing that can be given a new value.
The new value can be a float or a symbol.

1. If the Dollar variable is in an [object] box
   A Pd patch can be saved and used inside another patch. We then call it an abstraction.... and it is just like a programming sub-routine.
   If you want to use it many times then you have a problem, that they are all the same, so if you put an object [receive woof] they will all receive any message that you send with [send woof].
   That might well be what you want to do.
   But what if you want to send the message to only one of them?
   You can give it an [inlet], but your patch will get messy, and what if your patch needs to make its own mind up about which abstraction it wants to send the message to, maybe depending on which midi note it received?
   The solution is to give the abstraction arguments... some parameters that define it and make it different to the other copies.
   For example [my_abstraction]
   Let’s give it some arguments [my_abstraction 5 9 woof]
   Inside the abstraction, as it is created (you open its parent patch) the dollar variables will be replaced. Wherever you see $1 written IN AN OBJECT it has been replaced by the number 5.
   Number 5 because 5 is the first argument and has actually replaced the $1. You still see $1, but if you bang a [$1] object it will output 5.
   [f $2] will output 9
   [symbol $3] will output woof
   So if you have an object [receive $1-$3] then it has now become [receive 5-woof]
   And if you want to send it a message from outside, from another patch or abstraction, you will need to use [send 5-woof]
   Every Pd patch, which remember includes your abstractions, also has a secret number. The number is unique and greater than 1000. As Pd opens each patch it gives it the number, increased by one from the last number it gave.
   That number will replace $0 as the patch is created. You can find out what the number is by banging a [$0] object and connecting its output to a number box, or [print] object.
   $0 can be used in any object as part of the name or the address, which means that a message cannot escape from the abstraction. A sub-patch like [pd my-subpatch] will be given the same number.
   But from outside your abstraction you don’t know what it will be when the patch is created, so it is not useful. (A lie, you can find out, but as it can change every time you open your patch it is not worth the bother).
   Use it to send messages within your patch [send $0-reset] to [receive $0-reset] for example, because the message is absolutely unique to its window, so you know it cannot interfere with other abstractions.
2. If the Dollar $ variable in a [message( box
   Dollar $ variables are also replaced, but not as the patch is created (drawn by Pd as you open it).
   Dollar zero $0 has no meaning in a message box. It will produce a zero if the message is banged, but that is it.
   It is a mistake, a patching error, to put a $0 in a message box.
   $1 $2 $3 $4 etc. in a message box are replaced by incoming atoms (individual floats or symbols or whatever) when they arrive. $1 will be replaced by the first atom in the list, $2 the second etc.
   So if you have a message box [$1 $2 $3( ..... and you send into it a list [3 48 lala( .....then it will output 3 48 lala
   That is not really very useful.
   But it is actually very powerful.
   Make a list in a message box........ [33 12 wav(
   And bang it into a message box [open my-track$2-$1.$3( and you will get the output.........
   open my-track12-33.wav
   Which could be just the message that you want to send to [soundfiler]

David.

This is a spiritual successor to amPd. It's much more stable and has many more features than amPd:

• reads/writes metadata to/from patches. This is done by storing the info in the form of comments, in a canvas called [pd meta] or [pd info]. If no such canvas exists, foobar will add it in the top left-hand corner of your patch.

• comes with a Win32 Dialog UI element, containing sliders, toggles, buttons, and edit-text/button combos to send messages to your patch.

  • foobar looks in your patch for a canvas called [pd mix] and uses the parameters of whatever sliders, bang objects, or toggles it finds there to give your UI controls similar functionality.

How playback works

• libpd sends a 1 to vol, then a bang to play.
  • Generally this is where, in your patch, you have an [r play] hooked up to your metro, and an [r vol] connected to a [*~ ] before your output reaches [dac~].

• the length of the song is arbitrarily set by the user.
  • This affects the trackbar's cursor visibility and ability to set a position.
  • If the length is 0, there will be no trackbar cursor. Otherwise, the cursor, when moved, will send its position in seconds to pos. From there, it's up to your patch to take that information from [r pos] and work it into song events.

• The patch will not actually stop and move on to the next track until libpd receives a bang from [s stop].

How the mixer works

• all mixer controls go inside of [pd mix]

• horizontal and vertical sliders are turned into slider controls in the UI element
  • labels assigned to sliders in the patch become labels for the UI element's slider controls. The same applies for send symbols.
  • min and max values of sliders on the UI element work in integers only, so if you want a gradual shift from, say, 0 to 1, write "gradient" in the slider's receive symbol, and the slider's range will be broken down into roughly 200+ individual steps.
  • there are currently 7 sliders in the UI element

• bang objects with no label become simple buttons in the UI
  • their send symbols will be reflected in the button's name and they will send a bang when clicked.
  • there are currently 3 buttons

• bang objects with a label assigned become message buttons
  • these have an edit text field associated with them, where you can type out any message you want and send it to the destination.
  • the bang's label is placed inside of the edit text field as a suggested message to send.
    • pure data strips commas out of labels, so I'm using apostrophes to denote where commas should go. ex: do this' then this
  • there are currently 2 message buttons, with the 'any' button being a potential 3rd.

• a bang object with a label written in the format dest : msg will be assigned to the 'any' button.
  • the 'any' button has an editable destination field, giving you access to basically any receive symbol in your patch.
  • also substitutes as a third normal message button, when the other two are already in use

• toggles become checkboxes
  • each checkbox can have a label and send symbol assigned to it
  • there are currently 4 checkboxes

• right-clicking a track shows the context menu entry Pd Player -> Load mixer.
  • basically, you can load mixers of tracks not currently playing for some potentially interesting exchanges between patches. After loading the mixer, you still need to hit the Refresh button to show the changes.

foo_pd's copy of libpd.dll contains only the externals that I needed to run the example patches. If you want your own patches to work with foo_pd, you might need to make another build using MSYS2. If you're not sure which objects aren't instantiating, foobar's console prints all of pd's messages while audio is being processed. I'll also add more externals over time.

I'll be maintaining foo_pd at https://github.com/myQwil/foo_pd where you can also find the latest builds

foo_pd.zip
Last Updated: Feb 26, 2021 3:55pm EST

Hello,
I've been making guitar effects with Puredata and Raspberry Pi.
Previously I did not care much about this problem, but at the last moment I got a terrible problem so I would like to consult with you.

I created Puredata Patches on Windows 10, copy Patches to Raspbian and use it.
In most cases there is no problem,
but depending on the Patches the sound reproducibility will be different.
Please help if there is a solution,thank you.

Windows_And_Raspbian.mp4
test.pd

*I uploaded same files in Google Drive and Dropbox.

Google Drive

Dropbox

1)There is a problem with the reproducibility of the sound, especially the problem is remarkable with the decay sound.
2)The problem is reproduced even if Windows 10 and Raspbian use the same USB Audio interface(Behringer UCG102)
3)Even if I use a different USB Audio interface (Zoom U - 22) in Raspbian, the problem is reproduced.

Whew... that's a tricky one that I myself have attempted before. There are a few ways to potentially do this, but it depends on some things... Like nodsp said, the range is an important factor as well as the behavior of how it handles jumping between maximum and minimum values... and also the knob that is being used along with how the device handles sending the values received for that knob. If it spins endlessly, but stops sending values after after the knob turns past the minimum or maximum, thats a problem. If the knob reaches the min or max, and continues to send the min or max value each time the knob is turned past the value, then i'd do an endless encoder like this... endless-encoder.pd

To make a range constraint, just throw a modulo ( [%] ) object at the output, or something like [cyclone/wrap]

If the device being input does not send values once the knob goes past the limit, it becomes a bit more complicated. Youd have to take the expr object and set it so that when it receives a 0, it outputs 1 and if it receives a 127, it outputs 126, then route that back into the device to set the value so that you will get an output from the device on the next turn of the knob. does that make sense?

@whale-av Hello again, thank you very much for replying so quickly!

Ok so, the computer will always be a PC and will always have Pd installed so that makes things a lot easier I suppose (not sure what version it will be though, but since all those computers have only recently been equipped with Pd I'm assuming it's either vanilla or extended so it should be ok).
I just put my 17 sound files in the same folder and named them 1.wav ...... 17.wav. They are in the same folder as your patch now too.
Well, the numbers are not exactly "set", in fact, each sound file corresponds to a certain range of numbers. Ugh, I did it again, forgot to mention the range... Sorry..... I'd probably need a different object for a range... It's still kinda difficult for me to think in "computer" language about things related to music so that's why I'm forgetting to mention tons of stuff, but I'll try to fix that in this reply, sorry again!
I will just post the table to make it easier for you to understand.

But first, I would just like to explain how the table works. First I need to ask if it's possible to attribute the same numbers/range to different sound files, depending on the number's "place" within the combination? (You'll understand once you see the table.) Maybe it isn't and in that case I should think of a way to change the table according to what can be done?
So, there should be 13 numbers in total within the combination (13 numbers to type, like 13 empty slots waiting to be filled with numbers), but I said there are five sub-combinations. The first, second and fourth are 2 digit numbers, the third is a 3 digit number and the fifth is a 4 digit number. Obviously, three of these are 2 digit numbers, but the thing is I can't really choose the ranges (I have a set range for each sub-combination and can only try to figure out the easiest way to work with them) and the ranges are actually intertwined, So some numbers can be repeated, that's why I'm asking if the same numbers can be attributed to different sound files based on whether it's the first, second or fourth sub-combination. If that's too complicated or even impossible, I can only think of sacrificing a couple of sound files and just let the program play the same file twice instead.

Also important: is it possible to "condition" to program into playing a sound file based on the first combination, the first 2 digit number? Simply put through simple chords, say in the first combination you can type either 01 or 02, where 01 is A major and 02 is B major. Next, you can type in either 02 or 03, where 03 is E major (irrelevant right now), but 02 can be either D major or F sharp major (not A major like in the first combination), based on what the previous number was. If it was 01 (A major), then this time 02 will be D major, but if the first number was 02 (B major) then the 02 in the second combination should be F sharp major. IS something like this even possible, or do I need to figure out a way to go around this and alter my table? I CAN alter the table, but I can't work with the ranges of the combinations, or the number of the combinations, it must be 5.
Lastly, can different numbers be attributed to the same sound file based on their position within the combination?

Ok so finally here's the table, and I will just give you my current table so you can tell me if it's possible to do. I understand if it's too complicated and I need to change it! Maybe you can give me some tips on how to change it to make it the easiest to do in Pd.
1st SUB-COMBINATION
01-19 - 1.wav
20-22 - 2.wav
23-31 - 3.wav
2nd SUB-COMB.
01-03 - 4.wav (if the first was 01-19 or 20-22; or shorter, 01-22)
01-03 - 5.wav (if the first was 23-31)
04-06 - 6.wav
07-09 - 7.wav (if the first was 01-19)
07-09 - 8.wav (if the first was 20-31)
10-12 - 9.wav (if the first was 01-19)
10-12 - 10.wav (if the first was 20-22)
10-22 - 11.wav (if the first was 23-31)
3rd SUB-COMB.
900-975 - 4.wav (if the first was 01-19)
900-975 - 2.wav (if the first was 20-22)
900-975 - 12.wav (if the first was 23-31)
976-999 and 000-020 - 1.wav (if the first was 10-22)
976-999 and 000-020 - 13.wav (if the first was 23-31)
4th SUB-COMB.
01-09 - 7.wav (if the first was 01-19)
01-09 - 8.wav (if the first was 20-31)
10-69 - 14.wav (if the first was 01-19)
10-69 - 3.wav (if the first was 20-31)
70-99 - 6.wav (if the first was 01-22)
70-99 - 11.wav (if the first was 23-31)
5th SUB-COMB.
(this one is arbitrary so no matter what the last 4 numbers are, the sound file that is triggered should be based on the first combination, or something like that, so...)
xxxx - 15.wav (if the first was 01-19)
xxxx - 16.wav (if the first was 20-22)
xxxx - 17.wav (if the first was 23-31)

Now, I need to thank you if you had the patience to actually read all that and think about it..... I can only hope you could understand the idea, but please, if this is just too complicated, do tell me to change the table. Maybe, if you can or think I will understand, try to explain how the ranges work when playing sound files and how I can use that to my advantage to still keep all the sound files (or as many as possible) but make the thing easier to program.

Now I know I had a few more questions but I can't remember right now and I don't want to bombard you with everything all at once, I realize even this is way more than I could have asked for, you have been a huge help, really! Even if I don't entirely understand every single element of your patches, I did study them and used the help option like you advised me to, so I really am trying to get the hang of this. I completely understand if you just want to take a break from this if it's too complicated and time-consuming, I just ask that you give me some kind of feedback so I know what to expect!

Anyway, thank you for all your help and guidance until now, and for the guidance you'll provide in the future if you so choose!

Ok...... So I have been meaning to do this for a very long time......
I don't think it is the perfect "show_me_dollars" and so I will change it from time to time.
3rd attempt.........
show_me_dollars.zip
Here is a really terrifying screenshot, but I have also tried to explain it in words.
In many ways I think words ( below the screenshot) are easier to understand.
David.

Dollar $ variables in Pure Data patches.
A dollar variable is a thing that can be given a new value.
The new value can be a float or a symbol.

1. If the Dollar variable is in an [object] box
   A Pd patch can be saved and used inside another patch. We then call it an abstraction.... and it is just like a programming sub-routine.
   If you want to use it many times then you have a problem, that they are all the same, so if you put an object [receive woof] they will all receive any message that you send with [send woof].
   That might well be what you want to do.
   But what if you want to send the message to only one of them?
   You can give it an [inlet], but your patch will get messy, and what if your patch needs to make its own mind up about which abstraction it wants to send the message to, maybe depending on which midi note it received?
   The solution is to give the abstraction arguments... some parameters that define it and make it different to the other copies.
   For example [my_abstraction]
   Let’s give it some arguments [my_abstraction 5 9 woof]
   Inside the abstraction, as it is created (you open its parent patch) the dollar variables will be replaced. Wherever you see $1 written IN AN OBJECT it has been replaced by the number 5.
   Number 5 because 5 is the first argument and has actually replaced the $1. You still see $1, but if you bang a [$1] object it will output 5.
   [f $2] will output 9
   [symbol $3] will output woof
   So if you have an object [receive $1-$3] then it has now become [receive 5-woof]
   And if you want to send it a message from outside, from another patch or abstraction, you will need to use [send 5-woof]
   Every Pd patch, which remember includes your abstractions, also has a secret number. The number is unique and greater than 1000. As Pd opens each patch it gives it the number, increased by one from the last number it gave.
   That number will replace $0 as the patch is created. You can find out what the number is by banging a [$0] object and connecting its output to a number box, or [print] object.
   $0 can be used in any object as part of the name or the address, which means that a message cannot escape from the abstraction. A sub-patch like [pd my-subpatch] will be given the same number.
   But from outside your abstraction you don’t know what it will be when the patch is created, so it is not useful. (A lie, you can find out, but as it can change every time you open your patch it is not worth the bother).
   Use it to send messages within your patch [send $0-reset] to [receive $0-reset] for example, because the message is absolutely unique to its window, so you know it cannot interfere with other abstractions.
   Use it also for objects like [delwrite~ $0-buffer 100] or for an array name [array $0-array] so that in each abstraction they have a different name and you will not have problems with their being "multiply defined"...... as each name can only exist once in your patch.

2. If the Dollar $ variable is in a [message( box
   Dollar $ variables are also replaced, but not as the patch is created (drawn by Pd as you open it).
   Dollar zero $0 has no meaning in a message box. It will produce a zero if the message is banged, but that is it.
   It is a mistake, a patching error, to put a $0 in a message box.
   $1 $2 $3 $4 etc. in a message box are replaced by incoming atoms (individual floats or symbols or whatever) when they arrive. $1 will be replaced by the first atom in the list, $2 the second etc.
   So if you have a message box [$1 $2 $3( ..... and you send into it a list [3 48 lala( .....then it will output 3 48 lala
   That is not really very useful.
   But it is actually very powerful.
   Make a list in a message box........ [33 12 wav(
   And bang it into a message box [open my-track$2-$1.$3( and you will get the output.........
   open my-track12-33.wav
   Which could be just the message that you want to send to [soundfiler]

P.S. If the first item in the incoming list is a symbol then it will be dropped causing errors.
You can fix that by making the message a list by passing it through the object [list].
Unfortunately only messages starting with a float are automatically recognised as lists.

it's a recursive thing: I'll walk through part of an example:
say the list has 5 elements.
The list comes in, and goes into the open spigot.

so at this point the [t a a a a] is sending a list of 5 elements. the following is what happens to the right [list-split] at this moment:
the first 2 elements of the list are sent back to the upper trigger, and go back into the spigot, where they are split again into lists of length 1. element 1 goes back into the upper trigger and out of the outlet, and then the second does as well.

All of this happens before the list of 5 elements is even sent to the left [list split], because of the trigger. A similar thing occurs:
the last 3 elements of the 5-element list are sent to the upper trigger and into the open spigot, and then the first element of that is split off and sent out the outlet. Then the last 2 elements are sent through the spigot and split, and are sent out in order.

The crucial thing to understand is the recursive nature; it has to do with the depth-first message passing in pd.
The first half of the list is split off before the second half, and sent to be split in half again before the second half of the original list is even processed. So it goes the first half of the first half of the first half, etc. until the first element is sent to the outlet. Then it goes back up the "stack" to the second halves of the lists that it missed in doing the first half every time (this happens because of the triggers). So after the first element is sent, the second element is sent. After that, elements 3 and 4 (in a list since they weren't even processed to be split yet) are split and sent out in order. then elements 5-8, which are still in a list, are sent back and processed in the same manner.

Hopefully that's somewhat clear..

(rambling extra stuff:)
From a "computer science" perspective, you could say that you process the first half and put the second half on a "stack" , and then go into the first half, split it in half, put the second half on the "stack", etc. And then after the 1st element is put out, repeat that process for each thing on the top of the stack until you end up with 1 element:

in "pseudocode" (with a datatype "list" and an assumed stack):

function splitlist (list inlist) {
         list firsthalf;
         list secondhalf;
         if length(inlist) == 1 then {
                     output(inlist); -- pass the element
                     if stack exists then {
                            secondhalf = popstack(); -- get the next thing on the stack
                            splitlist(secondhalf); -- call the function recursively
                     }
        } else {
                   firsthalf, secondhalf = split(inlist); -- split the list, pass to variables
                   pushstack(second half); --- push the second half onto the stack
                   splitlist(firsthalf); -- call the function recursively
         }
}

I think that in reality most of this is taken care of in the computer's call stack, though not completely sure on how the memory for the lists is dealt with