Thanks David @whale-av for taking the time to help me, and also for pointing out that my message was almost unintelligible due to the dropped backslashes. What a nightmare... I edited it to make it look the same way I typed it, for future reference.

I presumed some contorted coding was involved in this difficulty, but if it also involves tcl then the situation is probably hopeless. Fortunately inserting all those whitespaces seems at least to provide a viable workaround.

Hi everyone!

I bumped recently into this difficulty and I am not sure if this is a bug or a feature: when I create a message with contents

;
pd-test.pd obj 10 10 expr $f1/$1;
pd-test.pd obj 110 10 expr $f1 / $1;

and I save and re-open this patch, the message reads

;
pd-test.pd obj 10 10 expr $f1/\$1;
pd-test.pd obj 110 10 expr $f1 / $1;

which is obviously interpreted differently because of the inserted backslash before the first $1. Apparently the space prevents Pd from inserting this backslash in the second line of the message. Is this the expected behavior? If so, is there a specification regarding escaped sequences and/or dollar signs appearing at the beginning or middle of symbols that explains it?

I would like to emphasize that my question refers exclusively to how PdFileFormat encodes and decodes Pd messages in general, and bears no relationship with the [expr] object or with dynamic patching (though the reference to them is obvious).

A follow-up difficulty has to do with the internal representation of the first message in the saved file, which is:

#X msg 10 135 ; pd-test.pd obj 10 10 expr $f1/\$1 ; pd-test.pd obj 110 10 expr $f1 / \$1 ;;

where Pd interprets the backslash in the symbol $f1/\$1 as an independent character. On the other hand, when I duplicate this message in Pd, the internal representation for the 2nd copy becomes

#X msg 10 135 ; pd-test.pd obj 10 10 expr $f1/\\\$1 ; pd-test.pd obj 110 10 expr $f1 / \$1 ;;

denoting that an independent backslash character would require to be backslash-escaped in the PdFileFormat. The fact that these two latter versions (with \$1 and \\\$1 in the file) appear and behave the same in the patch also struck me as unintuitive, so if anyone may shed some light into this I'd really appreciate.

Thanks in advance for your help!

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.

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

Thanks David! I forgot about the $s workaround for sending $0-names to [expr]. I'll follow your suggestion!

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:

1. the expr* family does not handle well the traditional convention "$0-name" (interpreted as "number minus") and "$0name" (invalid as a C identifier)

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

Hello!

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!

http://www.pdpatchrepo.info/hurleur/attach.zip

Hi there!

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!

Marcelo

http://www.pdpatchrepo.info/hurleur/arrayleakage.zip

In case that insterests anyone, Pd 0.40 solved this problem for the patches. The main window is even stranger-looking than before (very large ultra wide fonts), but I guess that's easier to change.

Thank you for your comments. I'll try and see if there is no bug report on the subject.

Regards.

Thank you for your reply!

I had explored this alternative, and although it solved the leakage problem,
it didn't solve my other problem, which was, I would still like to open this arrayleakagesubpatch and see the contents of the array without having to open another window.

If the first version's leakage is not actually a bug, then I probably misunderstood the function of the red sub-rectangle when you create graph-on-parent patches. This is quoted from the 0.39 release notes:

Graph-on-parent subpatches and abstractions no longer scale the GUI objects to fit the parent rectangle; instead you get a sub-rectangle in the subpatch, of the same size as the parent object, to place GUI objects in. GUI objects that don't fit inside aren't shown on the parent, and the parent objects no longer stretches itself to show things that wouldn't otherwise fit.

My point is: either that array should not appear on the parent (arrayleakage.pd) and this is a bug OR an array does not behave as either a GUI object or a regular object for the purpose of graph-on-parent subpatches, because those objects are supposed to be hidden on the parent. Is the latter the case? I wonder if this does not jeopardizes the whole idea of the red sub-rectangle.

Thanks again for your comments!