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!

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