I should point out that the patch version only works after the patch has been saved. So if you copy the compressed code and "File/New from Clipboard" it won't work properly until you save the patch (because it doesn't have a path until you save it somewhere). And obviously to see how it works as an app you have to build the app. This is all mac app stuff - I have no way to test this under windows.

I think that the problem is that thispatcher reports where the patcher that it is placed in is stored on disk. subpatchers are not stored on disk, at least not directly.

If you place the thispatcher in your top level patch, and have an inlet and outlet in your subpatcher to connect to the external thispatcher, I bet it works.

Thanks Chris. You are correct that does work.

I wasn't really concerned with how to get it to work. As I pointed out using the code as an abstraction or in a bpatcher works (and is easier to toss into any patch - I saved the second patch in this thread as "path.maxpat")

I was really just trying to figure out what was going on with the subpatcher. It seems odd to say that it isn't saved to disk when it gets saved with the top level patcher - but "not directly" as you said.

Another case of (me) being confused by what is and isn't communicated between the patch and the subpatch. Is this spelled out comprehensively anywhere in the documentation?

The problem with putting thispatcher in an abstraction/bpatcher is that it will return the path to the abstraction, not to the patcher in which it's embedded, which may not be what you want.

As far as this being spelled out in the doc somewhere, I don't really know. It's worked like this so long, that it just sort of seems like old knowledge to me; I know it's been discussed on the forum a few times.

That's very helpful. My "path" patch that I was using in the bpatcher, and as an abstraction, was in the same directory as my patch so I didn't catch that it was returning its own location and not the patcher that contained it. Thanks.

I think the comprehensive documentation that cycling provides is amazing. It's one of the ways that I was able to sell the college where I teach into buying 20 seats and offering Max as a Fine Arts elective. It's one of the things I stress to my students as I try to get across to them the importance of figuring this stuff out on your own. However,

The problem with "old knowledge" is that "new people" come along.

And perhaps the reason some of these things get discussed over and over is that they're not written down.

You're certainly right about there being some historical holes in the doc. Cycling ought to set up a system for documentation improvement requests.