Closing patches without Pd crashing, hopefully in an elegant way...
@nicnut It doesn't seem to be as easy as i previously thought.
Closing other patches isn't a problem, so i consider this solved. But closing the patch that triggers the process seems to be difficult.
There is a very hacky way that works, but is a little bit crazy: close-patches.zip
This works by modifying a secret patch that exists in Pd and close the main.pd patch from within that. A mechanism that checks whether the objects in the hidden patch are already created should be added, if you really want to go down this road.
But i would recommend using the [x]-button that comes with your OS to close the patch.
Edit: The secret patch should never be closed, only hidden. If you close it, graphical arrays will stop working and you will have to restart Pd.
Closing patches without Pd crashing, hopefully in an elegant way...
@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.
Closing patches without Pd crashing, hopefully in an elegant way...
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.
foo_pd - Pure Data plugin for foobar2000
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
Playing sound files based on numbers/sets of numbers?
@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!
Pure Data noob
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.
- 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.
- 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.
Serious Failure? Suddenly connections and abtractions were gone
@noise The sub-patches and arrays are stored inside the patch that contains them.
Abstractions are other patches that can be opened within the patch that they are "drawn" in, but have to be saved separately.
When you have a sub-patch visible and you save it you are actually saving the patch that "contains" it, and so you have to be careful (and of course when you save the patch it's sub patches are saved within it............ but the abstractions it contains are not re-saved if they have been edited.).
If connections are missing it is because the object that they connect to....... maybe an abstraction.... cannot be found, or dynamically created inlets or outlets within that abstraction have not been created, or have not been created before the lines are being drawn. Usually this happens because you have moved the abstractions somewhere outside of Pd's known path preferences, or you have zipped everything into a compressed folder.
The connection lines inside the patch are still there (e.g. #X connect 4 1 2 0;) but they cannot be drawn because the objects they connected to cannot be drawn.
So you should not need to rebuild your main patch.
You need to find out why Pd. cannot find the abstractions. Maybe it has lost it's path preferences?
David.
libpd on mac: clarification requested on expected behavior of cpp sample
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.
Loading a pure data patch ( .pd file ) within a pure data patch ( .pd file )
HI!
Quick version:
My folder structure:
/mother-patch.pd ( main pure data patch first loaded and running... )
/patches/1/main.pd
/patches/2/main.pd
/patches/3/main.pd
...
How i could open /patches/1/main.pd triggered by some action in the mother-patch.pd?
How i could close /patches/1/main.pd triggered by some action in the mother-patch.pd?
Long read
I'm attempting to clone the Critter and Guitari organelle ( link ).
This instrument is basically a computer running libpd and running very cool pure data patches
You can read more about my project here ( link )
I have a mother pure data patch that it's first loaded when the device is on, this patch is doing some [send] and [receive] operations related to the knobs/keyboard/volume/led and it should be also managing the loading ( opening and closing ) of the child pure data patches ( mentioned above ). This child patches are receiving the actions from the mother patch.
If I open the mother patch and the child patches manually, everything works fine. But now I need to OPEN this CHILD PURE DATA patches with a object within the mother patch.
I've been testing [open] , for opening the main.pd of the child patches but it does not work.
I've been testing [pd] , for opening the main.pd of the child patches but it does not work.
I wouldn't like to modify the original organelle patches.
I wouldn't like to end up loading all the patches using [pd ...] and inserting a [switch] object inside every main.pd file in the patches in order to enable only the dsp of the desired patch.
It would be perfect If i could have a folder with all the patches and load them within the mother patch with some kind of object. And I would also want to be able to CLOSE the pure data patch and open another ( changing patches... )
Every little and big help woul be MUCH APRECIATED!
THANKS!!!!!!!
New to PD, need help with notes failing to turn off.
I've been working on my first major patch for the past few months. It's a synthesizer based heavily on the tutorial on flossmanuals.net. After finally creating all of the features I wanted I started to modify the patch to make the synthesizer polyphonic. The catch is that I want to control the patch using the Mad Catz Mustang midi guitar controller. This controller works perfectly fine with the polyphonic synth in the PD help browser as well as with other polyphonic synth patches I've found online, so I do not think the controller has any problem interacting with the [poly] object.. The problem is that when I use it with my patch, some notes fail to turn off. It seems to happen most often when I quickly slur from one note to another. I did not have this issue when using the monophonic version of my patch. The amplifier subpatch is definitely receiving noteoff messages, but for some reason, they do not cause the envelope to close.
I think part of the problem has to do with the way the controller sends messages. I use the controller in 'tap mode,' meaning a noteon is sent whenever a fret button is pressed and noteoffs are sent when fret buttons are released. However noteoffs are also sent whenever any fret button is pressed in order to turn off the "open string" (A note can be played without pressing a fret button by striking the string sensors, and the only way to turn it off is by playing a fretted note). This occurs whether or not the open string is playing and I think this may be messing with [poly]'s voice allocation. I'm tempted to just say that the controller can't be worked around, but since I know it works for other patches I'm going crazy trying to fix my patch.
I understand it would be hard to duplicate this behavior without having the controller, but as I said before it works like a dream with other patches. I have tried to imitate the polyphony of these patches as best as I can. I've tried disconnecting and reconnecting objects in every order imaginable and I've tried delaying on and off messages in case they were somehow arriving to the amplifier envelope out of order.
Attached is a simplified version of my polyph[full poly help.pd] onic patch. I'd really appreciate it if anyone could give it a quick look over just in case there's anything really obvious that I'm just missing.
Thanks so much and have a great day.
EDIT: Please ignore the errors about missing {receive~}s or {catch~}es. The {send~}s and {throw~}s are for some of the features that I removed from this version of the patch for simplicity's sake but I did not remove the {send~}s and {throw~}s.