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":
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.
[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.
I'm using Pd vanilla 0.50-2, Ubuntu 20.04.
I'm struggling to find a naming convention for inserting $0 into identifiers that works seamlessly throughout Pd, given that:
the expr* family does not handle well the traditional convention "$0-name" (interpreted as "number minus") and "$0name" (invalid as a C identifier)
iemgui property dialogs change $0 to 0 when $0 is not in the first position
I would appreciate finding a workaround for (1). There is a workaround for (2) which is using #0 instead of $0 in iemgui property dialogs. I wouldn't call this workaround "seamless" for some reasons: (I) such a use is not to be found anywhere in Pd inline documentation nor in https://puredata.info/docs/manuals (I even tried https://git.iem.at/pd/iemgui with no success), turning it into a sort of alchemic secret (or more concretely, creating the impression that it may not be available in the long-term); (II) it makes dynamic patching as well as text editing pd patches much more convoluted (right now I'm writing sed scripts for changing naming conventions in hundreds of objects, and some demand $ but others demand #...).
The reason I'm writing here is to gather information on the matter. I can't figure out whether there is room for suggesting developmental improvements in either the expr family or the iemgui family, as far as dollarsign substitution is concerned. As per https://puredata.info/docs/manuals/pd/x2.htm#s6.5 the prefixed naming convention ($0-name) should be preferred, where it is also mentioned that "the expansion of variables (...) only works at the beginning of the symbol", but apparently such understanding has changed in recent implementations. From a user point-of-view, it would be amazing if expr* handled $0-names exceptionally as symbols and if iemgui's property dialogs handled $0 anywhere in send/receive symbols (as they already do in the first position, where $ is not substituted for #).
Last but not least, I apologize in advance for asking a question that most certainly has been asked before. The curse on dollarsigns and hashtags makes it also nearly impossible to find related messages in this forum, github, etc.
Does anyone know how to fix the appearance of Pd main window and patches when using a widescreen monitor? My fonts look horizontally stretched and objects and comments that usually appear fine do collide with this monitor (see images attached). All other programs look the same as they would in a 4x3 monitor. I thought it would have something to do with the file /usr/lib/pd/bin/pd.tk (also attached), I've tried to remove all -bold ocurrences within it, it looked slightly better, but still cluttered.
I use Pd 0.39-2 within Kubuntu (Edgy release). I have ttf-bitstream-vera and ttf-dejavu installed.
Thanks in advance!
I was trying to build a simple patch (arrayleakagesubpatch.pd attached) with some visible controllers, and an array that should only be visible when you open this patch. I am using Pd 0.39-2. I placed a bang within the red square defined in the graph-on-parent properties and the array outside this area. I assumed it would work just like other controllers (bangs, sliders), but apparently the information on the array leaks to the parent patch (see arrayleakage.pd attached), whereas other controllers (e.g. a bang) don't leak. I am not sure if this is a bug or a feature, so any comments are appreciated!
The only way I found to prevent this leakage was to remove the graph-on-parent property of the array (inside arrayleakagesubpatch.pd), but I really wanted to be able to see its contents when I open this file. I tried to push the array to a subsubpatch (so that the array would still be visible on arrayleakagesubpatch.pd), but it leaks to the parent anyway.
Any comments welcome! Thanks in advance!