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

sorry i didn*t follow the all the patches in this thread, but i had the same thing working with a raspi3 and this essential:

Thanks for all the responses. I am now going to put it all together in my Rpi with the python code that I have for opening patches.

@ingox I love the secret patch method. Just for stability I might stick with the 3 patches method. And thank you for pointing out [vis 0]. Really so many cool features in Pd, I have barely scratched the surface of this programming environment.

thanks, I'll mark this solved.

[EDIT: please refer to this post for a corrected version of this idea]

Hi there! Two years after the last message in this thread I was still trying to overcome this bug (it is a bug isn't it?) of a patch not being able to close itself gracefully.

Even though I was amazed at @ingox secret patch + dynamic patching solution, I think my workaround here may interest others.

It depends on two global names: a killer.pd patch and a killer global value.

When somepatch.pd wants to get closed, it sends this message |;pd open killer.pd .;kill_me symbol somepatch.pd<. [EDIT: actually it only works if you click on this message. If you connect a |bang< to it, it doesn't work anymore... please find the corrected version in this post.]

It is nice that the killer patch doesn't show up, and it has its own embedded garbage collector. The not-so-elegant part is that an invisible killer patch will be left dangling in the background. Of course you can always bring it to the front with |;pd-killer.pd vis 1< and close it yourself, if this bothers you.

@whale-av Amazing

@marcelo The [receive] object cannot change on the fly, but all the GUIs that have sends and receives in their properties can.
It a bit unreliable making changes remotely (through their "receive" name), but changes can be made locally...... simply sending in a message........ this.zip
So bangs and floats can be "dynamically" received.
David.

I'm glad everyone is working this out. I am now using a python script to just quit Pd and restart it with the patch I want. It seems to work. I have a little delay between the two steps to insure they don't overlap, because then I have some problems.

killer patches are good too, whatever works.

@ingox and @nicnut and everyone else....... I am withdrawing my post recommending a receive object.
I was mistaken........ it cannot work with a received message..... only with a mouse click.
Acutely embarrassed is what I am.
I will take it down once you have cancelled your upvotes.....

I don't know whether the hcs library is available for all platforms.
With [sys_gui] and [window_name] from that library the patch can be closed by a message generated within........... close_patch2.pd
It is available for windows 64-bit.
If you have it (and the withdraw command works for your OS) then this is I think a definitive solution.
It tells wish to close the window, rather than trying to close itself with [menuclose( and hanging Pd.
David.
BUT...!!!!! This method leaves hanging audio even though the patch closes cleanly...... see another post below "Because I made such a mess......" for a Vanilla and Extended solution...

@whale-av Not at all, this is working smoothly:

closetest.zip

@ingox True.... but this doesn't........ close_test2.zip
and that was the criteria from the OP...... that a patch should close itself with a menuclose message that it had sent to itself.
Leaving no open patch at all..... but Pd still running.
David.

@whale-av

@ingox Please stop upvoting me.... it's a mess...... It was just the [vis 0( messages fooling me.
I will continue, but obviously my age is affecting my ability to think the testing through properly.
@marcelo Yes, I am sorry. My power line was brought down by a tree or I would have almost instantly deleted the last post.
P.S. the HCS library solution does not actually close the patch either.
I will keep trying but maybe a -plugin will be the only way..... if there is a method in the tcl.
Or a script.
David.

Windows only Pd 32-bit only solution
(It relies on the windows keyboard/mouse apis).
gone.zip
The c file is there for anyone that can compile for windows... and I will have a go without any confidence at all.
Put input_event.dll and [input_event-help] into one of your Pd standard search paths.
It might need key numbers changing for your keyboard.
It sends Ctrl+W to the focused window....... so will need the [vis 1( message as provided...... to focus the window before sending the key events (if another patch has focus).
So it does exactly the same a clicking the red X to close the patch.
Your keys might not have the same numbers in your api so you might need to experiment using [key] and [key] doesn't return a value for Ctrl for me.
I used the value for Ctrl_R but I don't have that key on my keyboard.
The value for Ctrl_L did not work for me.
[input_event] can do mouse stuff as well...... see its help file.

For Linux and Mac there were suggestions for achieving the same result in the place where I first found the link to [input_event].......
http://codelab.fr/6655
In French but Google translate will give you a clue.... post back and ask if unsure.
David.

@marcelo So it is possible with a plugin (I do hope this works for you).
Vanilla and extended 32-bit and 64-bit but needs the hcs library.
It needs the HCS library, until I find another way.
I know it is possible with ::$focused_window but [sys_gui] will still be needed and ensuring window focus will be problematic when the patch receives a message.
Plugins need to go in a standard path so they are found as pd opens (or a path added to Pd path preferences) .
So put "close-plugin.tcl" in the pd/bin or pd/extra folder if you have set no other paths.
HCS_with_plugin.zip
Probably the last attempt for today.
David.

EUREKA! I solved the following problem:

Problem: provide a mechanism for allowing patches to self-close without Pd crashing.
Requirements: (1) uses only Pd vanilla; (2) action to close patch starts on the very patch that will be closed.

Solution: copy patch killer.pd in the same folder as the patch to be closed, and send a message containing ";pd open killer.pd <dir>;kill_me symbol patch_to_be_closed.pd":

killer.pd
patch_to_be_closed.pd

Comments: (documented in the killer patch) Pd doesn't deal well with menuclose requests that originate (in a direct chain reaction) from the same patch that wants to be closed, so a separate killer patch is needed, which can be opened by the same patch requesting to be closed. In order to break the direct chain reaction, the solution is to postpone this request and make it appear as being originated inside the killer patch. This is done by storing the received symbol and delaying the message menuclose by 0 ms, which is enough to issue a new chain of events. The killer patch stays alive (but invisible), and any new instances of the killer patch will silently kill the previous instances so that only one killer patch is alive at any given time. [EDIT: I included a safeguard [pipe 1] in the killer patch, check the inline comments]. This implementation fixes the problems with my previous solution and also with the 3-patches method by @ingox, both of which didn't work through a send/receive pair. It also does not depend on dynamic patching.

This has been tested in Pd 0.50-2 and Ubuntu 20.04. I appreciate feedback to confirm if it works in other platforms/versions.

@whale-av Thanks again David for the suggestions (hcs, mouse clicks)! I wasn't too keen on the idea of depending on external libraries, and I also had to abandom the idea of having the killer patch embedded in the patch to be closed.