I've been struggling to assign a valid local send symbol to a dynamically created vslider and somehow stumbled on this syntax:
dynamicPatchVerticalSlider.pd
I created the slider on the left by hand for comparison, and it appears that unless I use $\$0, Pd doesn't generate the correct pd file text, i.e.

#X obj 50 50 vsl 15 128 0 127 0 0 \$0_vsl_s empty empty 0 -9 0 10 -262144
-1 -1 0 1;

Wha??? Can anyone explain? I would have thought the escape sequence was \\\$0, i.e. a literal backslash followed by a literal dollar sign. For a number box, it's just #0 for some reason. Even crazier, that string in the message is encoded in the pd text file as $\\\$0!

@jameslo This is the page you will need for dynamic patching (unless that is where you stumbled)....... https://puredata.info/docs/developer/PdFileFormat
It has the syntax for all Pd GUIs

Yes, unfortunately some GUIs use # instead of $...... a legacy thing apparently that was probably to solve this very problem..... and if you type $ into the properties menu it is changed to # on saving.

No real idea about the escape codes except that I remember that in some interpreters $ is escaped by $....... so $ (seems true on this forum..... that was two dollars in the code quotes) rather than \$ but I don't think that is the case in tcl.
In tcl curly brackets should be used around the $ but sensibly we are not allowed to type them.
https://datacadamia.com/lang/tcl/backslash
But although a backslash escapes it has other meanings as well.

I remember giving the send/receive symbol a simple name and changing it afterwards by message to the GUI as when I was heavily into dynamic patching the backslash was not available in Pd.
Dynamic patches being by definition throwaways that was no problem.

But $\$0 seems sensible to me. I don't think the problem is the $.
The problem is that $0 in a Pd message becomes 0
The message hasn't gone to the interpreter at that stage?
So it is 0 that is escaped and added literally to the preceding $.
$\\\$0 for Pd reading its text file...... no idea...... and anyway I am probably wrong about $\$0 but that change does suggest that the string is being interpreted more than once before it becomes an object.

David.

@jameslo PS.
If you want to blow your mind take a look at proc ::tk::console::TagProc
Starting at line 769 in console.tcl

And if you do a text search within all files in the Pd folder you will find the GUI's that require \\\$ in their #X msg string for creating send/receive names.
David.

@jameslo I would have expected that a single backslash would be enough, i.e. \$0.

Interestingly, when i try both methods, the single backslash works, but the $\$0 one does not. No method works immediately, it only works after saving and reopening the patch. The source code of the patch seems also right.

dynslider.pd

@jameslo Here is a version that works immediately, using cut and paste. It is also stable after saving and reopening and the code looks good:

dynslider.pd

It only works if the subpatch is visible, a vis 1 can ensure this.

@jameslo Somewhere there is a thread I started and I think we sorted out the escape character logic, or I might have found the answer on the mailing list archives, can not remember. Why are you not just doing something like this? Am I missing something? Just trying to solve the puzzle?

@ingox seems to have just upvoted a post of mine in that old thread, so that may suggest something of worth there. That made it easy to find
https://forum.pdpatchrepo.info/topic/12649/adding-an-escaped-dollar-to-a-message

@oid This is a problem from my 2nd ever dynamic patch, so I wouldn't try to read deep meaning into my questions . Like my first dynamic patch, it's just a patch that generates the repetitive, static parts of other patches--a way to reduce the tedium of having to edit multiple send/receive names by hand, that's all. I'm expecting to have to cut and paste from this helper patch into the patch I'm really trying to write, so the value of $0 in the generating patch is irrelevant. Is that reasonable? In a patch that needed its UI to be dynamically generated, your way would make total sense, but I'm def not there yet. Also, regarding your other topic, I think the message that dynamically generates a vslider can itself be static, so I'm not sure that add2 technique is applicable.

@ingox OK, now I'm getting the same results as you, which is odd because the patch I've presented is just a small example from a larger patch that was giving me trouble. After discovering the $\$0 syntax I applied it to that larger patch, saw that it too was working, and then posted this topic. But now my larger patch is broken, which makes me believe that the system is behaving differently since running your patches (and that I wasn't previously hallucinating). But that can't be true, right?

So here's another small patch to demonstrate how my larger patch is (now) broken: dynamicPatchVerticalSlider2.pd

See how \$0 is just generating a 0 in the send symbol? When I save and reload it to test the fader (which doesn't work), the backslash gets dropped from the creation message!

So next I try falling back to the syntax I got working earlier, and the generated vslider send symbol looks good

and on reloading it I can confirm that it is good, but now I can't use my generating patch because $1 is backslash escaped!

@jameslo When i create the slider with $\\$0_vsl_s, the slider doesn't work. If i open the properties of the slider, it reads $0_vsl_s in send. If i click Ok, the slider is working. If i click Cancel, it still doesn't work. Clicking Ok sends the value for send again, but now changed, as the escaped characters are already resolved.

I mean, handling of escaped characters is always a little hard, but Pd has its specific quirks and also some bugs with it. So unexpected results ought to be expected.

@ingox Wow, I just replicated your result over here, that's crazy. So maybe @oid is right to suggest I need to dynamically generate the message that dynamically generates a vslider, to fix Pd's mangling of it? But wait, you've written tons of dynamic patching code--does it consistently work from release to release of Pd?

I have found dynamically creating the message to be much more reliable and it has worked consistently for me over the past few years. For reducing the tedium I have found exploiting the plain text format of pd patch files to be much quicker, the shell (bash/tcsh/etc) can do a great deal very quickly, a simple for loop is all it often takes, then just copy and paste the output into your patch or use the command line tools to redirect the output into the appropriate spot. I leave dynamic patching for those times when what is being created is in of itself dynamic, like if the number of v-sliders was variable and set by abstraction arguments.

Edit: the one time using the shell fails and dynamic patching is easier is when you need to connect with wires, things get ugly quickly, but for objects using send and receive it is not bad at all.

@oid

For reducing the tedium I have found exploiting the plain text format of pd patch files to be much quicker

which is funny because I was about 10 minutes into using [text] to build the Pd file before I wondered why I was reinventing the wheel. Now I know? I'm gonna play with your method first though. But you're also right that this is mostly just about solving the puzzle.

@jameslo Some objects are finikity and require the whole properties list for dynamic patching.
Try this........ hmm.pd
It also completely avoids escaping $0......... which adds to the confusion... but it is as I thought.... you cannot write $0 in a message.
What must happen is that the $1 and $2 in the message are replaced by $ and 0 and written directly and individually to the object properties as it is created.

Sorry to be so slow....... I had a niggling itch about this so I trawled some old patches...... my memory is failing........
David.

@whale-av Amazing, that makes things clearer while sidestepping Pd's (probably flawed) escape syntax. I just tried it on my larger patch and it works perfectly. Here's a screenshot for those who are just browsing:

Key takeaways:

• neither message box contains fancy escape sequences, just plain $n substitution
• a list message can contain literal chars like '$'
• the generated vslider works immediately, without having to reload or cut/repaste or OK the properties
• the generating messages don't get mangled when the patch is saved and recalled
• don't be lazy like me and just assume you can leave off the parameters you don't care about

@whale-av @jameslo Is there a reason to do these serial lists instead of just [pack f $0]? It seems like it could have some advantages but I can not quite put my finger on it.

@oid because $0 in [pack] refers to the local identifier of the current patch, whereas we want the literal "$o" to be inserted into the send string of the vslider, so that the vslider uses the local identifier of whatever patch it gets copied into.

@jameslo I knew I was missing something. I guess you are just doing from pd what I normally do from the shell. Useful bit of knowledge either way, suspect it will come in handy on occasion.

Noticed a little note in the new help files for [text fromlist] regarding its $argument expansions, an escaped $ with become a literal $ in the text with no escape, combine this with [text get] and we get a literal $0 out which the add/add2/set methods do not try and expand or escape. While not very useful for $0 where the above [list $ 0 $1( is easier, this works in more situations without getting awkward and after many hours of fighting with it, I think it may be the only way to get a dynamic send into a message properly.