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

@nicnut It crashes in Windows too.
You can use [namecanvas] like this......... this.zip
Where sending the message [menuclose( will close........ in this example..... any window named "bonzo"...... but there can only be one canvas named bonzo open, or it will crash as well.
I think it solves your problem though as I understand you will only have one open at any time..

If you want to save it first before closing then use the message [menusave, menuclose( sent to bonzo.
Put [namecanvas bonzo] in every patch that you would have used the closepatch receive object.....
Maybe choose a less stupid sounding name than bonzo........
David.

Yes, the correct message is [menuclose( instead of [menuclose 1(. With this it is at least possible to close another open patch.

The same patch still crashes over here, but there is a possible workaround. I will post this later.

Hi @whale-av and @ingox.

Wow the namecanvas object is exactly what I was looking for. I can put that in every patch and not have to type in the name and have to change it with each version of the patch. Thank you!

This system of closing patches works on my Mac, but still crashes Pd on Rpi. I also tried doing the same thing in "close_patch5" where I added a namecanvas object in that patch and sent a bang to a [menuclose( to a [s thenameofthecanvas] and that crahsed pd.

if either of you have more insight into this, or a way this can work on Rpi please let me know.

Thank you for the help,

@nicnut Yes......... having re-read your op I see you want close_patch_5 to close as well afterwards but leave Pd running..... hmm..... I don't know yet.
Is [namecanvas] working and actually closing [closetest1] cleanly on the RPI from [close_patch_5]....?
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.

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

@nicnut Yes, a patch closing itself seems to be the problem. Your approach with a patch that stays open and closes the others seem to be a reasonable way.

OK thank you both for the help.

The 3 patch method seems to work and I can cut the delay time down to less than one second so this might be the way to go.

Thanks.

Nick

@nicnut Just one more thought on this: If you use your 3-patches-method, you can send a [vis 0( message to the patch that closes the others directly after opening the patch. You can also use [namecanvas( for this.

This way the closer patch stays hidden and the solution is more clean.

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