hello again
I've had a strange occurrence happen where all the sub patches of patch had the 'pd' prefix to the name changed to a square block character that is ascii 1 (start of heading). I've no idea why or when the corruption occurred. It may have something to do with [key] and editing using ctrl key.
Its possible to duplicate the sub patches but not copy & paste
Has anyone else come across this
Cheers Balwyn

Have you been fooling around with iemguts/canvasname? That can do things like this to the subpatch name, but I don't see it in your patch.

If not, open the .pd file as text. A subpatch entry would usually look like #X restore 213 94 pd slot-13;, so search for the word "restore" and post what you find.

@liamG Thanks, No [canvasname] in this patch
Yes, I checked the text when I used a hex editor to see what character it was.
I was wrong about copying. You can copy/paste the whole object, but you cant copy the text for a new object.
oddness.txt

In the text file there are two spaces before the "slot-1"--this is what was causing the strange character. If you remove the extra space then you'll have a subpatch without the "pd" prefix. Is that what you're aiming for?

Incidentally, why aren't you using abstraction here? It looks like a situation where abstraction would be useful, although I assume you have a reason.

@liamg I forgot to mention that the sub patches still work perfectly.
the first space is actually ascii 1.
I have many copies of this patch that I copy or 'save as' and 99% are still intact and still show eg [pd slot-1]. I would just like to know what caused the corruption. Even the [pd make-folder] sub patch has the same corruption.

Each of the sub patches has a different receive and a slightly different message within and at the time decided sub patches were easier and local and works.

Its the save/load subpatch for my soon to be uploaded 'stamp album v2' project. but I worry that this may re-occur.

Cheers
Balwyn

The patch looks great--can't wait to see it!

I turned the text file you uploaded into a patch and got the same block when I opened it. Then I removed the extra space from the text file and when I re-opened it, the block was gone. So I'm pretty sure that it's the space that's causing the problem. Where the space came from I do not know.

I'm sure you know this, but you can dictate an abstraction's send and receive channels through creation arguments. So [send $1-$2] will be [send $0-s1] if the abstraction's creation arguments are "$0 s1" and [send $0-s2] if the creation arguments are "$0 s2"

You can also determine messages using [list $1 $2 $3...] and [list trim]. This gets a bit harder if the messages are of different length, but it can still work. If you'll allow for externals, [iemguts/canvasargs] allows you to do this much more dynamically.

Finally, as an extra special trick, you can use creation arguments in the name of a sub-abstraction to allow for as much divergent behaviour between two instances of an abstraction as you want. See this example: sub-abstraction.zip . This might not be what you need here, but it can be really useful!

@LiamG Thanks for that example. I am sure I'll have a use for it.