I am getting a different result in my code when I run a patch as a an abstraction vs on its own. The issue seems to be with a list append object and the right cold inlet. The patch does the following:

1. takes a number input
2. pass the number input to the hot side of the list append
3. if the number input is <= 127, pass 1 to the right cold side of list append else if it is 128 or greater pass 1 + 1 (2) to the right cold side list append.
4. format the list in a message, print the message
5. and also print the value of the data directly.

Here is the abstraction patch:

Here is the main patch:

When I run the main patch and enter 127 then 128 into the number atom I get the following output in the console:

first problem is the number out of range. Second problem is that the $2 value in the message is not the same as the value printed from "print result".

When I run the patch on its own and use the number atom in the patch for the value I get a different output in the console:

In this case the value of "print result" and the $2 value in the message are the same.

It seems there is a difference in the order of execution of the print statements and maybe there is also a difference in order of when the cold inlet on the list append gets updated.

Why is there a difference when run as an abstraction and how do I correct the number out of range error?

thanks for your 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.

@whale-av Yes, the first patch closes fine, but the 2nd patch that closes it is crashing Pd.

I was thinking of another possibility. I could have 3 patches, and one just stays open the whole time, which would be the patch that closes all the other patches.

I would open my first patch. My 2nd patch would be the one that I would use to perform. Then when I want to change patches for a performance I open the 3rd patch that sends some kind of trigger that the 1st patch uses to close the 2nd patch, and then it closes the 3rd patch. The 1st patch just stays open till I shutdown.

It's a convoluted scheme, but that way I can avoid a patch needing to closes itself, which I think is what the problem is.

Hi,

I have a headless Rpi setup using Pd .49.

I am trying to have everything automated, and one thing I'm trying to work out is that I want to close the patch I'm using before I open the next patch. I am doing this by sending internal Pd messages.

I used to quit Pd and re-open it, but due to problems I couldn't resolve after much time connecting my midi controller, I am going to try to just close my patch rather than quit and reopen Pd.

What I've worked out is that every patch will have a [r closepatch] object, and when I want to change patches I will open a patch that will send a bang from [s closepatch] , then it will close itself. I added several seconds of delay time to both patches, but this method always causes Pd to crash.

I am using this message to close a patch: [; pd-mypatch.pd menuclose 1(

My question: How can I close a patch from another patch, and then close the patch that closed the first one? Or is there a better way.

Even better, is there a way that I don't have to enter in the name of the main patch I want to close, like can I use some sort of variable, or send another internal message that will load the patch name into the patch closing message?

I am attatching what I have. First open "closetest1.pd" then "close_patch5.pd" If you connect the messages you can test them properly, but they always make Pd crash on my Rpi.

Thank You.

closetest1.pd

close_patch5.pd

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

@Gabriel-Lecup If you just want to loop at normal speed then you can use [tabplay~]
It will be sample perfect.
You just have to deal with waveform mismatch at the loop point..... which will cause clicks.
If you want to change the playback speed then you have another problem.
Artefacts are unavoidable. Well I will qualify that. As you reduce the playback speed you have to increase the original sample-rate of the Sample compared to your output sample-rate to avoid them. Half speed... double the sample-rate of the Sample. You cannot do that in Pd as far as I know.

If you cut the playback speed in half. This causes everything to sound an octave lower because the time stretching makes all the soundwaves twice as long, which means their frequencies will be cut in half and thus sound an octave lower.
This leads the problem that every single sample you use needs to be played twice or else there will be gaps (a much worse "artefact"). To avoid this problem you can use [tabread4~], which interpolates intermediate values that it generates using information from the values that ultimately precede and follow it.
If you increase the playback speed then samples are dropped. This unavoidably creates artefacts as well. As you say, with a tone they will be audible.
Filters can help with high frequency ringing, but might already be built into the object.... though probably not, because you can see the ringing in [B04.tabread4.interpolation].pd in the doc folder.

Someone might know whether [tabread4~] (or [tabread4~~] even), uses quadratic or cubic interpolation. Checking the processing overhead might tell you....... https://www.maximalsound.com/mastering/interpolation methods.pdf

You need to add 2 samples to the array for [tabread4~] ((see [tabread4~-help])) to do it's math playing back the whole sample.
I had never thought about it, but 2 zero samples should probably be inserted after a loop point to allow the curve to interpolate to zero. This would also avoid any post Sample clicks. But how?

I assume that [tabread4~~] which seems not to be available to me on windows, uses double precision.
That will give more accuracy for bit depth, but the samples still arrive at the same speed, so I cannot see how it helps you here. 64-bit precision interpolation over 32-bit precision. Audible? I would be very surprised.
If it is working well for the patch that @beep.beep has kindly posted then I can only assume that [tabread4~~] deals automatically with the 2 sample overhang.

David.

pd extended offered this functionality as a built in feature from what I hear. Unfortunately, pd-extended is a bit dated and no longer maintained... that said, if your patch does not require features from the latest releases of puredata, you could build it in extended and use it's make-app function. If that won't work for you, then making a standalone app from a puredata patch is still possible, but not exactly a simple task. There are actually several ways that you could do this, all of which will likely require some knowledge of coding in other languages like C, java, python etc. If you were looking to make something for mobile devices, there are apps available that can wrap your patch to run in it's own app container type of thing in android and ios. For that, check out pddroidparty, libpd and mobmuplat. If you want to run a patch as a vst type plugin within a DAW, check out pdpulp, chamomile and the one that is i think windows only, pdvst.

If your only need to make a standalone app is to cater to people who are less computer savvy, then I would say that the amount of effort it would take to make a truly standalone app from a pd patch is probably overkill and then some. You could much more easily make a patch that functions somewhat like a standalone app, in that you click an icon and the patch opens up and runs, by creating a launch script. How you would go about doing this would depend on what OS you are using. OSX and linux both run on unix, so a bash script that launches pd and opens the patch with all the desired settings could be written, marked executable (sudo chmod +x <filename>) and assigned an icon. A script could even be made to automate the installation of puredata to go with it.

If you want to be really thorough, you could compile/build a version of puredata from source, making sure all the needed dependencies are contained within the source directory and linked accordingly, and house it in a bundled folder (something like all applications and .kext files on OSX operate,) But once again, this would have some caveats, has it's own learning curve and is generally no simple task for someone who isn't already well versed in these types of things. The easiest thing would probably be to just install pd for your clients manually or via script and make a launch script that they can just click on and have it automatically open pd and the patch of choice.

Hope that helps

@whale-av Hello, first I just want to say thank you very much for your help and sorry for not replying sooner, I read all the messages, I just didn't want to bother people before I had an actual issue or a question that I understood enough to know how to ask what to do next. So that's why I'm only replying now. And you're totally right, I have suffered and learned in the past day so my brain's kind of all over the place right now, I'm still struggling to get the hang of this and really understand the patches you sent me (thank you so much for taking the time to make them for me!).
To answer your questions, I will not be assessed for this part of the project, it doesn't matter much how I do it as long as it works because no one will look at the project anyway, the end result is what matters in this case. The only "limitation" is that it has to be done in Pd. Also, my version of Pd is Vanilla (I'm assuming that doesn't change your patch much since you said it'd work in that version), and actually no, there's not really a next stage to this project; all I'm supposed to do is get my sound files to play in a loop when I press Enter (after I've typed all my numbers) and to be able to stop the loop again with Enter. I probably should have mentioned that oops, does that mean I need another keyup object or would the one in the patch work for both starting and stopping the sound?
I actually had a patch of my own but it was very simple and mostly improvised based on what I managed to learn (like I said, completely new to this) and nothing like yours so it probably wouldn't have worked anyway... Is it ok if I use your patch as a starting point? If it is, I'm assuming the next step would be the abstractions. From what I understand, abstractions are used for referencing and reusing old patches in order to keep the new patch clean and not messy. I do need something like that, as I have 17 wav files ready to use. But not all 17 should be used in one loop. I actually only need 5 sound files per loop (like in your patch), but the total number of files I can choose from is 17. To be able to tell the program which file to play based on its corresponding number I probably need the select object, right? Would I need it within the calling patch or the patch being called, a.k.a. abstraction (if my thinking is right, it's probably the calling patch)? There's probably an easier way to do this than an x number of select objects but I'm just not familiar enough with the program, sorry... Also, what difference does it make if it's not 1-digit numbers, but 2-digit, 3-digit and 4-digit combinations? To be more precise, the first, second and fourth sound file should correspond to a 2-digit number, the third to a 3-digit number, and the fifth to a 4-digit number (and I can't change this unfortunately, it's part of the task).
Oh, and is there a way I can make this work on any computer, for example if I copy my files onto a flash drive? Or if I can't, would it drastically affect my main patch if I changed the sound file destinations later, once I know what computer is going to be doing all this? Would I need to change the file destinations in all the patches or would it be possible to do so automatically via abstractions, by changing them in the main patch only (probably not but eh I asked...)?
This is all probably waaay too advanced for a beginner (and I have no idea why they'd give me this task without any prior preparation.......) so I realize I might be asking for too much here, and maybe I'm getting ahead of myself, but I still hope you could give some advice on what to do from here, what's the next step, the elements I need to get this done etc. I'm not in too much hurry, I have time until the 5th of February, so it's ok if you don't have the time for me right now, I can wait a bit!
Thank you so so so much, even just sending me the first patch was such a huge help, thank you! And I hope you can guide me through this for a bit longer!

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.

Thanks for those links Monetus. I'm pretty close with my existing setup and will first try to work with that when I have some more time. Some of the output from the samples/cpp/pdtest appears to be as expected.

However, from main.cpp

    cout << endl << "BEGIN Patch Test" << endl;
    
    // open patch
    Patch patch = pd.openPatch("pd/test.pd", ".");
    cout << patch << endl;
    
    // close patch
    pd.closePatch(patch);
    cout << patch << endl;
    
    // open patch again
    patch = pd.openPatch(patch);
    cout << patch << endl;
    
    // process any received messages
    //
    // in a normal case (not a test like this), you would call this in
    // your application main loop
    pd.processFloat(1, inbuf, outbuf);
    pd.receiveMessages();
    
    cout << "FINISH Patch Test" << endl;

the response

BEGIN Patch Test
Patch: "pd/test.pd" $0: 1003 valid: 1
Patch: "pd/test.pd" $0: 0 valid: 0
Patch: "pd/test.pd" $0: 1005 valid: 1
PD: PATCH OPENED: 1003
print: 0
PD: PATCH OPENED: 1005
print: 0
FINISH Patch Test

seems right but no patch was opened and if I already opened that patch before running the executable, none of the print messages (called later in the code) showed up in the console of pd. I'll focus on this and try to repost to the forum when I have a better idea of what is going on.