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

@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.